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FOREWORD 


1 .  This  standard  defines  the  Government’s  requirements  and  expectations  for  contractor 
performance  in  defense  system  acquisitions  and  technology  developments. 

2.  This  revised  SMC  standard  comprises  the  text  of  The  Aerospace  Corporation  report  number 
TR-0001  dated  28  February  2013,  entitled  Systems  Engineering  Requirements  and  Product,  and 
contains  the  following  major  changes: 

•  Test  Like  You  Fly  requirements,  as  reviewed  by  industry  and  documented  in  The 
Aerospace  Corporation  report  TOR-2012(1315)-3,  Rev  A,  dated  12  December  2012. 

•  Human  Systems  Integration  requirements,  as  reviewed  by  industry  and  documented  in 
The  Aerospace  Corporation  report  TOR-201 2(8960)- 1,  Rev  A,  dated  12  August  2012. 
[Note:  reformatted  from  a  standalone  document  to  Section  4.3.1 1  of  this  document.] 

•  Update  of  referenced  documents  to  current  versions. 

•  Minor  editorial  updates  and  corrections  reported  by  users. 

3.  Beneficial  comments  (recommendations,  changes,  additions,  deletions,  etc.)  and  any 
pertinent  data  that  may  be  of  use  in  improving  this  standard  should  be  forwarded  to  the  following 
addressee  using  the  Standardization  Document  Improvement  Proposal  appearing  at  the  end  of  this 
document  or  by  letter: 


Division  Chief,  SMC/ENE 
SPACE  AND  MISSILE  SYSTEMS  CENTER 
Air  Force  Space  Command 
483  N.  Aviation  Blvd. 

El  Segundo,  CA  90245 


4.  This  standard  has  been  approved  for  use  on  all  Space  and  Missile  Systems 
Center/ Air  Force  Program  Executive  Office  -  Space  development,  acquisition,  and 
sustainment  contracts. 


Mr.  David  Davis,  GG-15,  DAF 
SMC  Chief  Systems  Engineer 


Mr.  Thomas  Fi 
SMC  Directi 


SMC/ENE 


Contents 


Change  History . iii 

Abstract . v 

Acknowledgments . vii 

Foreword . ix 

1.  Scope . 1 

1 . 1  Document  Purpose . 1 

1 .2  Document  Organization . 1 

2.  Referenced  Documents . 3 

3.  General  Requirements . 5 

3 . 1  Systems  Engineering  Process  Application . 7 

3.1.1  Support  to  the  Capability  Needs  Process . 7 

3.1.2  System-Level  Constraints,  Concepts,  and  Architectures . 8 

3.2  Systems  Engineering  Requirements . 9 

3.2. 1  Requirements  Analysis  and  Validation . 9 

3.2.2  Functional  (Logical)  Analysis . 1 1 

3.2.3  System  Element  Design  Solution  and  Validation . 12 

3.2.4  Design  for  Implementation,  Deployment,  Operations,  and  Support . 13 

3.2.5  Implementation . 15 

3.2.6  Integration . 15 

3.2.7  Design  Solution  Verification . 16 

3.2.8  Design  Solution  Validation . 18 

3.2.9  Application  Across  the  Life  Cycle . 20 

4.  Detailed  Requirements . 23 

4. 1  System  Analysis . 23 

4.1.1  Assessments  of  System  Effectiveness,  Cost,  Schedule,  and  Risk . 24 

4.1.2  Tradeoff  Analysis . 26 

4.1.3  Decision  Analysis . 27 

4. 1 .4  Operational  Analysis  and  Assessment . 28 

4. 1 .5  Environmental  Analysis  and  Impact  Assessment . 29 

4. 1 .6  Training  Analysis  and  Assessment . 29 

4. 1 .7  Transition  (Deployment)  Analysis  and  Assessment . 30 

4.1.8  Supportability  Analysis  and  Assessment . 30 

4. 1 .9  Disposal  Analysis  and  Assessment . 31 

4.1.10  Mission  Critical  Fault  Analysis  (MCFA) . 31 

4.2  Systems  Control . 32 

4.2.1  Management  and  Control  of  the  Systems  Engineering  Process . 32 

4.3  Specialty  Engineering  Analysis  and  Control  Contributions . 39 

4.3.1  Parts,  Materials,  and  Processes  (PMP) . 39 

4.3.2  Structures . 40 

4.3.3  Manufacturing . 40 

4.3.4  Quality  Assurance . 41 

4.3.5  Test . 41 

4.3.6  Survivability . 42 


4.3.7  Environmental,  Safety,  and  Occupational  Health  (ESOH) . 42 

4.3.8  Contamination . 43 

4.3.9  Mass  Properties . 43 

4.3.10  Logistics . 44 

4.3. 1 1  Human  Systems  Integration  (HS1) . 45 

4.3. 12  System  Security  and  Information  Assurance . 49 

4.3.13  Reliability . 49 

4.3.14  Electromagnetic  Interference  and  Compatibility  (EMEEMC) . 50 

4.3.15  System  Safety . 51 

5.  Notes . 53 

5.1  Intended  Use . 53 

5.2  Systems  Engineering — Concept . 54 

5.3  Data  Requirements . 56 

5.3.1  T adoring  Guidance . 56 

5.3.2  Tailoring  Considerations . 57 

5.4  Robustness  and  Flexibility . 58 

5.5  Evolutionary  Acquisition . 59 

6.  References . 61 

Appendix  A:  Foundation  for  the  Systems  Engineering  Process . 63 

Appendix  B:  Acronyms . 67 

Appendix  C:  Definitions . 71 

APPENDIX  D:  HUMAN  SYSTEMS  INTEGRATION  PLAN . 87 


Figures 


Figure  3-1.  Example  of  systems  engineering  process . 5 

Figure  3-2.  Systems  engineering  process  described  by  a  “Vee”  diagram . 6 

Figure  3-3.  Relationship  between  minimum  essential  systems  engineering  requirements 

and  baselines . 7 

Figure  4-1.  Engineering  control  activities . 33 

Figure  5-1.  Flexible,  robust,  and  optimized  systems . 59 


Tables 


Table  3-1.  Development  Stages  for  Increasing  Accuracy  and  Completeness  of  the 

Program  Baselines . 20 


1.  Scope 


1.1  Document  Purpose 

This  standard  defines  the  government’s  requirements  for  a  disciplined  systems  engineering  approach 
to  system  acquisitions.  It  specifies  the  government’ s  requirements  for  executable  contractor  systems 
engineering  efforts  and  can  also  be  used  as  a  guide  by  the  tasking  agency/activity  to  assist  in  systems 
engineering  planning  and  management.  Government  agencies  (Department  of  Defense  and  the 
intelligence  community)  should  use  this  document  as  a  compliance  document  for  system  acquisition 
contracts.  It  is  also  applicable  to  non-DOD  government  (NASA  and  others),  civil,  and  commercial 
developments. 

This  document’s  objective  is  to  define  the  essential  work  products,  produced  in  the  systems 
engineering  process,  needed  to: 

Adequately  define  a  system  over  its  life  cycle  such  that  the  integrated  system  when  deployed: 

a.  Provides  at  least  the  threshold  or  minimum  required  capabilities  and  requirements  and  is 
affordable,  but  otherwise  balances  capability,  cost,  schedule,  risk,  and  the  potential  for 
evolutionary  growth 

b.  Is  defined  by  operations  concepts,  operational  capabilities/requirements,  system 
architectures,  specifications,  drawings,  technical  orders,  training  documents,  maintenance 
facilities  and  equipment  documents,  verification  and  validation  plans,  procedures,  and 
reports 

c.  Includes  the  documented  processes  that  are  essential  to  build-to,  buy-to,  code-to,  verify- 
to,  deploy-to,  train-to,  operate-to,  support/sustain-to,  and  dispose-to  over  the  system  life 
cycle 

d.  Has  system  definition  products  satisfying  this  objective,  referred  to  as  the  system 
configuration  baseline 

Define  products  that  can  be  used  throughout  the  intermediate  development  stages  by  the  tasking  and 
performing  activities  to  plan,  monitor,  and  control  the  progress  over  each  phase  and  contract  of  the 
system  acquisition  program. 

1.2  Document  Organization 

Each  systems  engineering  functional  (process)  area  is  presented  in  this  document  using  the  following 
format: 

( 1 )  Functional  area  requirement 
Required  systems  engineering  products 
Required  product  characteristics 

Each  general  requirement  stated  in  the  requirements  sections  contains  the  contractor’s  requirement  for 
performance  of  the  specific  systems  engineering  function/process  as  expressed  in  a  “shall”  statement. 
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Each  section  titled  “Required  Systems  Engineering  Products”  provides  a  list  of  products  required  to 
comply  with  the  general  requirement.  The  section  titled  “Required  Product  Attributes”  describes  the 
characteristics  of  each  required  systems  engineering  product. 
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2.  Referenced  Documents 


The  following  documents  are  referenced  in  this  standard  or  have  been  used  as  information  sources. 

The  order  of  presentation  does  not  imply  an  order  of  precedence. 

•  Department  of  Defense  Directive  5000.1,  May  12,  2003 

•  DOD1  5000.02,  Operation  of  the  Defense  Acquisition  System,  December  2,  2008  (and 
associated  Directive  Type  Memorandum:  DTM  09-027,  Implementation  of  the  Weapons 
System  Acquisition  Reform  Act  of  2009,  dated  December  9,  201 1) 

•  CJCS1  3 170.0 1G,  Joint  Capabilities  Integration  and  Development  System,  2009 

•  DOD  Architecture  Framework,  Version  2,  May  28,  2008 

•  DOD  5000.4-M-l,  Cost  Analysis  Guidance  and  Procedures,  April  18,  2007 

•  DOD  5010. 12-M,  Procedures  for  the  Acquisition  and  Management  of  Technical  Data 

•  DODD  4630.5,  DOD  Information  Technology  Standards  Registry,  May  5,  2004 

•  DODI  4630.8,  Global  Information  Grid 

•  AFI  63-101/20-101,  Integrated  Life  Cycle  Management,  March  7,  2013 

•  MIL-HDBK-881C,  Work  Breakdown  Structure,  October  3,  201 1 

•  Defense  Acquisition  Guidebook  (current  version) 

•  SMC  Systems  Engineering  Primer  &  Handbook  (3rd  Edition),  April  29,  2005 

•  SMC  Systems  Engineering  Specialty  Engineering  Disciplines  (Volume  2,  1st  Edition), 
October  3,  201 1 

•  INCOSE  Systems  Engineering  Handbook  (Version  3),  June  2006 

•  SMC-S-021,  Space  and  Missile  Systems  Center  Standard:  Technical  Reviews  and  Audits  for 
Systems,  Equipment,  and  Computer  Software,  September  15,  2009 

•  SMC-G-1202,  Space  and  Missile  Systems  Center  Guide:  Space  Flight  Worthiness,  October 
2009 

•  SMC-S-016,  Space  and  Missile  Systems  Center  Standard:  Test  Requirements  for  Launch, 
Upper  Stage,  and  Space  Vehicles,  2008 

•  ISO  17666:2003,  Risk  Management 

•  SMC-S-0 1 3  (2008),  Reliability  Program 

•  TMCR  86-01,  U.S.  Air  Force  Technical  Manual  Contract  Requirements,  24  February  2010 

•  TOR-20 13(8960)-3,  The  Aerospace  Corporation:  SMC  Compliance  Specifications  and 
Standards,  28  February  2013  (or  current  version) 

•  NRO  Enterprise  Best-Engineering-Practices  Repository  -  NEBR  (current  version) 

•  NASA  Systems  Engineering  Handbook,  NASA  Report  NASA/SP-2007-6105  Rev  1, 
December  2007 

•  ALAA  S-l  17-2010,  Space  Systems  Verification  Program  and  Management  Process, 
November  2010 

•  DOD  FAR  Supplement  227.405-70,  Data  Requirements 
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Aerospace  TOR-201 l(8591)-2  Volume  1,  Space  Vehicle  Test  and  Evaluation  Handbook, 
Chapter  15:  Test  Like  You  Fly  -  Assessment  and  Implementation  Process  for  Pre launch 
Mission  Testing,  2012 

Aerospace  TOR-2010(8591)-6,  Test  Like  You  Fly:  Assessment  and  Implementation  Process, 
2010 

AF1  99-103,  Capabilities  Based  Test  and  Evaluation,  SMC  Supplement 

Beutelschies,  G.,  “That  one’s  gotta  work”  -  Mars  Odyssey’s  use  of  a  fault  tree  driven  risk 
assessment  process,  Aerospace  Conference  Proceedings,  2002,  IEEE,  Volume  2,  pp.  651-671 


3.  General  Requirements 


This  section  defines  the  concurrent  engineering  environment  and  required  systems  engineering 
activities,  tasks,  and  products  across  the  system  life  cycle  for  any  system,  including  new 
development,  upgrade,  modification,  resolution  of  deficiencies,  or  development  and  exploitation  of 
technology.  These  tasks  are  to  be  performed  throughout  the  system  life  cycle;  however,  the  focus  and 
outputs  of  the  tasks  will  be  highly  dependent  on  when  they  are  performed  during  the  life  cycle. 

The  systems  engineering  process  is  an  iterative  process  starting  with  requirements  analysis, 
proceeding  to  functional  (logical)  analysis  and  requirements  allocation,  and  then  to  design  solution 
(synthesis),  as  depicted  in  Figure  3-1. 


Process  input 

Customer  needs/objectives/capabilities 
Technology  base 

Specifications  and  standards  requirements 
Requirements  from  prior  development  effort 
Program  decision  requirements 


± 


Requirements  analysis 

Analyze  missions,  concepts,  and  environments 
Identify  functional  requirements 
Define/refine  performance 
Define/refine  performance  design  constraints 

Requirements  Loop 


Functional  analysis  and  allocation 

Decompose  to  lower-level  functions 

Allocate  performance  and  other  limiting  requirements 
to  all  functional  levels 


> 


Define/refine  functional  interfaces  (internal/external) 
Define/refine/integrate  functional  architecture 

Design  Loop 

Synthesis 

Transform  architectures  (functional  to  physical) 

Define  alternative  system  concepts,  configuration  items,  and 
system  elements 

Select  preferred  product  and  process  solutions 
Define/refine  physical  interfaces  (internal/external) 


System  analysis 
and  control 

Tradeoff  studies 
Effectiveness 
analysis 

Design  analysis 
Risk  management 
Configuration  mgmt. 
Interface  mgmt. 

Data  mgmt. 

Performance 
measurement 
Technical  reviews 


Process  output 

•  Architectures 

•  Specifications 

•  Engineering  design 

•  Decision  database 


Figure  3-1.  Example  of  systems  engineering  process. 
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Iterations  can  occur  between  these  activities  or  via  the  verification  and  validation  feedback  loops. 
Systems  analysis  and  control  are  to  be  performed  throughout  the  systems  engineering  process. 
Section  5  provides  the  detailed  requirements  for  systems  analysis  and  control. 

The  systems  engineering  process  also  must  support  top-down  recursions  to  develop  the  system  at 
increasingly  detailed  levels  and  bottom-up  recursion  during  assembly/integration.  The  recursive 
nature  is  further  depicted  in  the  “Vee”  diagram  of  Figure  3-2.  Both  generic  processes  depicted  in 
Figures  3-1  and  3-2  typically  apply  to  the  development  of  complex  systems. 
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Figure  3-2.  Systems  engineering  process  described  by  a  “Vee”  diagram. 

Section  3  defines  the  general  requirements  corresponding  to  the  systems  engineering  (SE)  activities 
presented  in  Figure  3-1.  This  SE  activity  flow  is  further  expanded  in  Figure  3-3  to  provide  a  cross- 
reference  between  the  standard  SE  activities  and  the  requirements  presented  in  this  document. 
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Figure  3-3.  Relationship  between  minimum  essential  systems  engineering  requirements  and 
baselines. 

3.1  Systems  Engineering  Process  Application 

a.  The  contractor  shall  apply  a  comprehensive  systems  engineering  process  that  is  mutually 
agreeable  to  the  contractor  and  contracting  agency. 

b.  The  contractor  shall  document  the  comprehensive  systems  engineering  process  and 
management  plan,  the  Systems  Engineering  Management  Plan  (SEMP),  to  be  used 
throughout  the  procurement  and  update  as  required. 

c.  The  results  of  systems  engineering  process  activities  shall  be  captured  and  stored  in  a 
repository,  including  all  analysis  results,  assessments,  trade  studies,  or  verification.  This 
repository  includes  all  decisions  and  the  rationale  for  those  decisions  so  that  they  can  be 
recreated  throughout  the  life  of  the  program. 

3.1 .1  Support  to  the  Capability  Needs  Process 

a.  The  contractor  shall  participate  with  the  customer,  if  contractually  directed,  in  developing, 
refining,  and  updating: 
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(1)  The  statements  of  capability  need  thresholds  and  objectives  corresponding  to  identified 
capability  gaps. 

(2)  The  architectural  products,  including  the  applicable  operational  and  systems  views. 
Apply  the  guidance  and  approaches  provided  in  DOD  Architecture  Framework  (current 
version)  and/or  other  architectural  approaches  as  directed  by  the  customer  and  to  meet 
specific  engineering  challenges  and  objectives. 

(3)  The  identification  of  alternative  materiel  approaches  and,  for  the  selected  materiel 
approach(es),  alternative  operational  and  system  concepts  that  could  fill  capability  gaps 
and  that  offer  potential  for  further  refinement  and  subsequent  development. 

(4)  The  operational  scenarios  and  concept  of  operations  (CONOPS)  for  the  operational  and 
system  concepts  under  consideration  to  fill  the  capability  gaps. 

(5)  The  assessment  of  the  relationship  between  capabilities  and  evolutionary  growth  in 
capabilities,  on  the  one  hand,  and  the  life  cycle  cost,  schedule,  and  risk  for  the  materiel 
approaches  or  system  concepts  that  could  provide  the  capabilities,  on  the  other  hand,  to 
highlight  those  capabilities  that  drive  cost,  schedule,  or  risk. 

(6)  The  development  of  approaches  for  transitioning  from  a  current  system,  if  any,  which 
is  ultimately  to  be  replaced,  curtailed,  or  supplemented  by  the  new  capability. 

(7)  The  definition  of  technology  developments  and  other  risk  mitigation  steps  for  potential 
future  action  toward  the  development  of  promising  system  concepts. 

(8)  Sustainment  strategies. 

(9)  Definition  of  the  threat  environment  (based  on  and  referenced  to  Defense  Intelligence 
Agency  (DIA)  or  Service  Technical  Intelligence  Center  approved  documents) 

(10)  Operational  test  and  Like  You  Fly  test  planning. 

(11)  Assignment  of  mission  objectives  to  priority  levels. 

b.  The  contractor  shall  immediately  bring  any  inconsistencies  identified  between  the  above 

systems  requirements  and  the  activities  of  the  government’s  capability  needs  or  operational 

capability  requirements  process  to  the  attention  of  the  customer’s  contracting  officer. 

3.1.2  System-Level  Constraints,  Concepts,  and  Architectures 

Using  the  data  forming  the  systems  engineering  process  foundation  (see  Appendix  A)  that  have  been 
provided  or  approved  by  the  government,  the  development  contractor  shall  define  the  initial  system 
concepts  to  be  used  as  inputs  to  the  system  engineering  process  and  develop  the  associated  required 
systems  engineering  products  with  the  product  attributes  specified  in  this  document. 


3. 1.2.1  Required  Systems  Engineering  Products 


a.  Validated,  approved,  and  maintained  integrated  architectural  views  that  characterize 
interrelationships  between  the  system  and  its  elements  and  the  interoperability  of  the  system 
with  other  system,  units,  and  forces. 

b.  Source  and  basis  for  engineering,  including  tradeoffs  or  other  analysis  for  each  architectural 
selection. 

3. 1.2. 2  Required  Product  Attributes 

a.  The  architecture  products: 

(1)  Represent  the  system  and  its  integration  to  achieve  the  operational  capability 
requirements  and  to  support  engineering  trades  and  analyses. 

(2)  Trace  to  the  allocated  functional  and  physical  elements  from  which  the  architectural 
elements  are  derived. 

(3)  Trace  to  the  capabilities  for  which  the  system  is  being  designed  and  to  the  missions  for 
which  it  is  intended.  Traceability  is  to  be  maintained  in  both  directions — top-down  and 
bottom-up — to  identify  requirements  without  parents  and  requirements  that  don’t 
spawn  children.  This  traceability  between  mission,  capability,  and  architecture 
characteristics  is  to  be  maintained  and  kept  up  to  date  at  all  times. 

(4)  Include  required  architecture  products  defined  in  the  DOD  Architecture  Framework 
(DODAF). 

(5)  Include  standards  contained  in  the  current  approved  version  provided  by  the  DOD 
Information  Technology  Standards  Registry  (D1SR). 

(6)  Provide  an  integrated  architecture  for  interoperability  that  extends  and  is  consistent 
with  any  architectural  views  provided  by  the  customer  (or  otherwise  identified  by  the 
contractor  and  sanctioned  in  writing  by  the  customer). 

3.2  Systems  Engineering  Requirements 

3.2.1  Requirements  Analysis  and  Validation 

The  contractor  shall  perform  requirements  analysis  and  validation  to  develop  the  associated  required 
systems  engineering  products  with  the  product  attributes  specified  in  this  document. 

The  requirements  analysis  and  validation  activity  is  initiated  to  define  the  requirements  baseline,  then 
continues  throughout  the  development  process  to  also  define  the  allocated  and  design  release 
baselines. 

3. 2. 1.1  Required  Systems  Engineering  Products 

a.  Validated,  approved,  and  maintained  requirements  baseline  captured  in  a  draft  System 
Specification,  and  then  final  System  Specification,  and  system-level  Interface  Control 
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Documents  (ICDs)  or  interface  specifications  defining  all  system-level  requirements  and 
constraints  and  their  allocations  to  the  next  lower  level. 


b.  Documented  system  architecture  and  requirements  traceability. 

c.  Source  and  engineering  basis  including  each  tradeoff  or  other  analysis  for  each  system-level 

system  performance  and  functional  requirement  and  its  allocations  to  the  lower  levels. 

3. 2. 1.2  Required  Product  Attributes 

a.  The  requirements  baseline: 

(1)  Includes  and  traces  to  the  operator/user  capabilities  for  which  the  system  is  being 
designed  and  to  the  missions  for  which  it  is  intended. 

(2)  Includes  analyses  of  each  lower-level  requirement  to  ensure  that  it  is  valid,  necessary, 
and  current,  and  satisfies  the  higher-level  capabilities,  requirements,  or  constraints  from 
which  they  resulted. 

(3)  Consists  of  verifiable  requirements  with  the  method  of  verification  documented. 

(4)  Includes  system  interoperability  needs,  including  any  interface  constraints  identified  in 
the  approved  concept  documents  and  the  operational  and  system  architecture  views. 

(5)  Includes  all  functional  and  performance  requirements  and  constraints  and  those 
imposed  by  each  specialty  function  (see  Subsection  4. 1 ). 

(6)  Includes  all  constraints,  including  external  and  internal  interfaces  and  operating, 
launch,  transportation,  and  storage  environments;  and  design  constraints  for 
interoperability,  security,  safety,  human  factors,  reliability,  maintainability,  and  all 
other  relevant  constraint  categories. 

(7)  Results  from  documented  decision  trade  studies  (tradeoffs)  that  balance  system 
effectiveness,  life  cycle  cost,  schedule,  risk,  and  the  potential  for  evolutionary  growth. 

(8)  Is  validated  through  customer  review  and  documented  agreement/approval  to  ensure: 

(a)  Compliance  with  the  above  attributes. 

(b)  A  balanced  solution,  including  system  effectiveness,  life  cycle  cost,  schedule,  risk, 
and  evolutionary  growth  potential  issues. 

(9)  Is  documented  and  controlled  in  a  system  specification  and  system-level  1CD  as 
applicable. 

b.  The  system  architecture  and  requirements  traceability  matrices: 

(1)  Provide  two-way  traceability  between  the  requirements  baseline  and  the  requirements 
source. 
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(2)  Trace  among  the  architecture  and  system  technical  requirements,  capabilities,  and 
missions  upward  to  mission  and  downward  to  functional  and  performance  requirements 
at  the  system  level. 

(3)  Trace  from  the  system  technical  requirements  to  the  requirements  baseline  and,  as  they 
are  developed,  the  allocated,  design  release,  and  product  configuration  baselines. 

(4)  Are  maintained  such  that  changes  to  any  requirement,  capability,  system,  software,  or 
physical  component  are  identified  and  updated  for  each  applicable  item  in  the  matrices. 

c.  The  basis  for  each  element  of  the  requirements  documentation  includes: 

(1)  Supporting  rationale  for  requirement  statements  determined  from  the  requirements 
analysis,  functional  analysis,  and  design  trades  results  and  be  linked  to  the  element  of 
the  requirements  baseline. 

(2)  Verification  statement  associated  with  each  requirement  and  verification  method  of 
analysis,  inspection,  demonstration,  or  test. 

3.2.2  Functional  (Logical)  Analysis 

The  contractor  shall  perform  functional  (logical)  analyses,  allocations/assignments,  and  validation 
iteratively  based  on  tradeoffs  to  develop  a  functional  architecture  or  logical  representation  of  the 
system  and  develop  the  associated  required  systems  engineering  products  with  the  product  attributes 
specified  in  this  document. 

3.2.2. 1  Required  Systems  Engineering  Products 

a.  Logical  solution  representations  (functional  architectures). 

b.  Mission  critical  fault  analysis  (MCFA). 

c.  Engineering  basis  is  documented  for  all  functional/logical  solutions. 

3. 2. 2. 2  Required  Product  Attributes 

a.  The  resulting  logical  solution  representation  (functional  architecture): 

(1)  Accurately  and  completely  reflects  the  minimum  or  threshold  required  operational 
capabilities  consistent  with  concepts  of  operation,  system  behavior,  and  required 
functionality. 

(2)  Accurately  and  completely  reflects  the  functional  and  performance  requirements  in  the 
requirements  baseline. 

(3)  Accurately  models  the  system  behavior  to  include,  but  not  be  limited  to,  all  sequencing, 
concurrency,  and  timing  requirements. 

(4)  Includes  data  flow  relationships  that  provide  data  associations  necessary  to  derive 
requirements  from  the  functional  or  logical  analyses. 
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(5)  Is  sufficiently  defined  to  form  the  basis  for  detailed  and  precise  functions  or  logical 
elements  and  their  allocated  or  derived  performance/functional  requirements  at  the  next 
lower  level. 

(6)  Is  decomposed  to  lower  levels  to  the  point  that  each  can  be  related  to  elements  of  the 
physical  hierarchy  to  form  the  allocated  baseline,  and  the  allocation  of  the  system 
performance  requirements  and  design  constraints  to  the  lower  levels  is  complete. 

(7)  Includes  the  relationships  to  the  physical  implementation  and  is  documented  in  the 
decision  database. 

(8)  Includes  the  definition  of  both  the  internal  and  external  interfaces,  and  addresses  the 
physical  implementation,  as  well  as  the  logical  issues,  such  as  data  formats,  data 
semantics,  etc.,  as  they  apply.  Uses  industry  standard  interface  technologies  and 
protocols  as  applicable. 

(9)  Has  a  decision  for  each  decomposition,  grouping,  sequencing,  timing,  iteration,  and 
concurrency  that  is  chosen  shall  be  supported  by  documented  tradeoff  or  other  analysis. 

(10)  Is  validated  through  customer  involvement  to  ensure: 

(a)  Compliance  with  the  above  attributes. 

(b)  Two-way  traceability  between  each  element  of  the  requirements  baseline  and  each 
element  of  the  functional  architecture. 

(c)  Two-way  traceability  between  each  element  of  the  functional  architecture  and  the 
functional  and  physical  elements  of  the  system-level  architectures. 

(d)  The  assessments  that  all  requirements  can  be  met  and  are  consistent  with  cost  and 
schedule  constraints. 

b.  Mission  critical  fault  analysis  (MCFA)  includes: 

(1)  List  of  mission  critical  failures  that  can  cause  loss  of  mission  or  inability  to  execute 
mission. 

(2)  For  each  mission  critical  failure,  the  fault  analysis  with  potential  flaw  contributors. 

3.2.3  System  Element  Design  Solution  and  Validation 

The  contractor  shall  determine  the  design  solution,  support  validation  of  the  design  solution,  and 
develop  the  associated  required  systems  engineering  products  with  the  product  attributes  specified  in 
this  document. 

3. 2. 3.1  Required  Systems  Engineering  Products 

a.  The  validated,  approved,  and  maintained  allocated  (design-to)  baseline  in  specifications  and 
interface  documents  grouped  by  each  system  element  such  as  segment,  subsystem, 
component  (hardware  and  software),  computer  software  unit,  and  part. 
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b.  Design  reference  timeline. 

c.  Engineering  basis  documented  for  all  design  solutions. 

3. 2. 3. 2  Required  Product  Attributes 

a.  The  allocated  baseline: 

( 1 )  Identifies  all  system  products  and  establishes  the  interactions  of  the  system. 

(2)  Documents  the  assessment  of  alternative  solutions;  identifies  and  quantifies  decision 
criteria;  and  analyzes  decision  uncertainties. 

(3)  Includes  the  design-to  technical  functional  and  performance  requirements  and  design 
constraints  for  each  product. 

(4)  Includes  all  derived  design-to  requirements  and  design  constraints  for  each  product. 

(5)  Includes  all  internal  and  external  interfaces  and  addresses  how  the  interface  will  be 
implemented,  including  operational  usage  descriptions  for  transactions  originating 
before  and  ending  after  a  defined  interface,  as  well  as  the  logical  issues  such  as  data 
formats,  data  semantics,  etc. 

(6)  Includes  the  verification  method(s)  selected  for  each  requirement. 

b.  The  Design  Reference  Timeline  shall  include  a  literal  timeline  or  sequence  of  functional 

requirements  for  each  mission  phase. 

3.2.4  Design  for  Implementation,  Deployment,  Operations,  and  Support 

The  contractor  shall  design  the  products  that  constitute  the  system  implementation  (fabrication  and 

code)  and  sustainment  assets,  and  develop  the  associated  required  systems  engineering  documentation 

with  the  attributes  specified  in  this  document. 

3. 2. 4.1  Required  Systems  Engineering  Products 

a.  The  validated,  approved,  and  maintained  design  release  baseline. 

b.  Engineering  basis  documented  for  all  design  solutions. 

3. 2. 4.2  Required  Product  Attributes 

a.  The  design  release  baseline: 

( 1 )  Fully  satisfies  the  allocated  baseline. 

(2)  Identifies  all  additional  system  products  necessary  to  manufacture,  code,  author,  or 
buy;  integrate;  verify;  deploy;  train;  operate;  support/sustain;  and  dispose  of  the  system 
and  its  constituent  products  over  the  life  cycle. 
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(3)  Is  designed  to  implement  interoperability  with  both  internal  and  external  interfaces  for 
all  mission  phases. 

(4)  Systematically  derives  functionality  from  the  operationally  stated  interoperability 
constraints. 

(5)  Integrates  the  functional  and  physical  interface  designs  and  associated  functions  and 
requirements  across  systems. 

(6)  Incorporates  nondevelopmental  items  (NDI),  commercial  off-the-shelf  (COTS), 
precedented  designs,  technologies  at  the  customer-specified  technology  readiness  level 
(TRL)  (refer  to  the  SMC  Systems  Engineering  Primer  and  Handbook  [1]  for  TRL 
descriptions)  and  modular,  open  systems  approaches  when  such  alternatives  can  satisfy 
the  requirements  and  allocated  baselines  and  the  resulting  design  balances  system 
effectiveness,  life  cycle  cost,  schedule,  risk,  and  potential  for  evolutionary  growth. 

(7)  Ensures  that  the  reused  item  has  been  qualified  in  the  conditions  specified  for  the  new 
application. 

(8)  Requires  only  part  types,  materials,  and  processes  that  have  been  fully  characterized 
prior  to  their  design  application  and/or  can  be  fully  qualified  prior  to  use  for 
verification,  flight,  or  delivered  product. 

(9)  Includes  the  identification  of  limited  life  products  and  age-sensitive  materials,  and  the 
procedures  for  managing  such  products. 

(10)  Includes  the  identification  of  safety  hazards  and  procedures  for  safe  handling,  storage, 
and  operations. 

(11)  Is  validated  through  customer  involvement  to  ensure: 

(a)  Compliance  with  the  above  attributes. 

(b)  Two-way  traceability  between  each  element  of  the  requirements  baseline  and  each 
element  of  the  functionally  architecture. 

(c)  That  assessments  of  the  system  effectiveness,  life  cycle  cost,  schedule,  risk,  and 
evolutionary  growth  potential  show  that  the  requirements  baseline  can  be  feasibly 
and  affordably  satisfied. 

(d)  That  LYF  tests  to  support  design  decisions  are  architected  and  designed  to  reflect 
mission  usage,  including  appropriate  selection  of  mission  characteristics,  and 
critical  fault  risk  assessment  for  deviations  from  mission  characteristics  or  usage. 

b.  The  basis  for  each  design  selection: 

( 1 )  Is  linked  to  the  applicable  element(s)  in  the  design  release  baseline. 

(2)  Includes  the  source  requirement  in  the  allocated  baseline  and  the  tradeoff  or  other 
analysis. 
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3.2.5  Implementation 


The  contractor  shall  build,  code,  or  buy  the  products  that  make  up  the  system  to  include  the 
implementation  (fabrication  and  code)  and  sustainment  assets. 

3. 2. 5.1  Required  Systems  Engineering  Products 

Product  configuration  baseline. 

3.2. 5.2  Attributes 

The  Product  Configuration  Baseline: 

a.  Defines  the  system  to  its  lowest-level  components  that  are  fabricated  or  coded  in  a  manner 
that  fully  satisfies  the  Design  Release  Baseline  over  the  system  life  cycle. 

b.  Includes  all  additional  system  products  necessary  to  manufacture,  code,  author,  or  buy; 
integrate;  verify;  deploy;  train;  operate;  support/sustain;  and  dispose  of  the  system  and  its 
constituent  products  over  the  life  cycle. 

c.  Is  validated  through  customer  involvement  to  ensure  two-way  traceability. 

3.2.6  Integration 

The  contractor  shall  integrate  lower-level  elements  (such  as  components,  software  units, 
configuration  items,  computer  software  configuration  items,  and  systems)  into  the  next  higher  level 
and  develop  the  associated  required  systems  engineering  products  with  the  product  attributes 
specified  in  this  document.  Integration  activities  are  performed  with  approved  assembly/integration 
and  verification  procedures  at  each  level  of  the  buildup. 

The  contractor  shall  allocate  LYF  validation  tests  to  appropriate  levels  of  hardware,  software,  and 
hardware/software  integration;  to  appropriate  vendors;  and  to  levels  of  mission  functional  integration. 
The  customer  or  customer  representative  shall  coordinate  multiagency  and/or  multicontractor  LYF 
integration  test  planning  and  discrepancy  resolution. 

3. 2. 6.1  Required  Systems  Engineering  Products 

a.  Assembly/integration  and  verification  procedures. 

b.  Discrepancy  reporting,  causal  analysis,  and  corrective  action  procedures. 

c.  LYF  test  architecture  and  design  plans,  LYF  test  procedures,  LYF  test  exceptions  and 
associated  fault  risk  assessment,  and  LYF  test  results  and  discrepancies. 

3. 2. 6.2  Required  Product  Attributes 

a.  The  documented  assembly/integration  and  verification  procedures  include: 

(1)  Defined  integration  roles  and  responsibilities  of  all  contractors  and  government 
participants. 
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(2)  Assembly/integration,  verification,  and  LYF  test  validation  of  component/software  unit 
interfaces  and  mission  functionality/interoperability. 

(3)  Assembly/integration,  verification,  and  LYF  test  validation  of  hardware/software  item 
interfaces  and  mission  functionality/interoperability. 

(4)  Integration/verification/validation  of  system  and  support  interfaces  and  mission 
functionality/interoperability. 

b.  Discrepancy  reporting,  causal  analysis,  and  corrective  action  procedures  are  integrated  with 

the  assembly  and  verification  procedures  and  LYF  test  validation  procedures. 

c.  LYF  test  information  is  correlated  to  provide  context  and  significance: 

(1)  Each  test  objective  is  mapped  to  mission  phase  objectives,  first-time  events,  mission- 
critical  events,  and/or  fault  paths. 

(2)  Test-specific  exceptions  are  mapped  to  mission  characteristics  and  MCFA  fault  paths. 

(3)  Each  test  discrepancy  is  mapped  to  identified  associated  test  exceptions  or  MCFA  fault 
paths,  where  possible. 

3.2.7  Design  Solution  Verification 

The  contractor  shall  verify  the  system’s  design  and  development  to  confirm  that  the  system  meets  all 
documented  requirements  (using  A1AA-S-1 17-2010  for  space  systems)  and  develop  the  associated 
required  systems  engineering  products  with  the  product  attributes  specified  in  this  document. 

3. 2. 7.1  Required  Systems  Engineering  Products 

a.  Documented  system  verification  program. 

b.  Verification  results. 

c.  Design  qualification  data. 

d.  Acceptance  verification  data. 

e.  The  validated,  approved,  and  maintained  product  configuration  baseline. 

f.  Mission  critical  fault  analysis  (MCFA). 

3. 2. 7.2  Required  Product  Attributes 

a.  The  system  verification  program: 

(1)  Quantitatively  verifies  that  each  system  product  (whether  new,  modified,  ND1,  or 
COTS)  meets  all  of  its  allocated  requirements  and  design  constraints  in  accordance 
with  the  verification  method  for  each  requirement  or  constraint  in  the  allocated 
baseline. 
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(2)  Includes  system  effectiveness  evaluation  and  manufacturing  process  proofing. 

(3)  Addresses  verification  requirements  and  criteria  for  solution  alternatives;  definition  of 
verification  to  demonstrate  proof  of  concept;  and  development,  qualification, 
acceptance,  pertinent  operational,  and  other  testing. 

(4)  Addresses  life  cycle  requirements  for  test  consistency  in  and  across  the  solution  set. 

(5)  Addresses  the  requirements  and  procedures  needed  to  verify  critical  verification 
methods  and  processes  (such  as  key  methods,  assumptions,  and  data  used  in 
verifications  by  analysis). 

(6)  Includes  progressive  verification  that  product  and  process  designs  satisfy  their 
requirements  (including  internal  and  external  interfaces)  from  the  lowest  level  of  the 
physical  hierarchy  up  to  the  total  system. 

(7)  Correlates  identified  discrepancies  with  respect  to  the  product  configuration  baseline, 
technical  performance  metrics,  and  constraints. 

(8)  Maintains  a  record  of  all  discrepancies. 

b.  Verification  results: 

(1)  Verify  required  performance  of  all  critical  characteristics  by  demonstration  and  test. 
Where  total  verification  by  demonstration  or  test  is  not  feasible,  testing  verifies  key 
characteristics  and  assumptions  used  in  the  design  analysis  or  simulation. 

c.  The  design  qualification  data: 

(1)  Provides  the  verification  method  for  each  requirement  in  the  requirements  and  allocated 
baseline  and  each  verification  requirement  in  the  design  release  baseline. 

(2)  Confirms  that  the  design  of  the  system  (hardware  and/or  software)  complies  with  each 
requirement  and  constraint  in  the  requirements  baseline  and  that  the  design  of  each 
system  product  and  integrated  assembly  of  products  that  is  separately  documented  in 
the  allocated  and/or  design  release  baselines  complies  with  each  of  its  requirements  and 
constraints. 

(3)  Confirms  that  each  component  (hardware  and/or  software)  has  adequate  design  margin 
to  account  for  the  uncertainties  over  the  system  life  cycle. 

(4)  Is  based  on  all  applicable  verification  data  obtained  by  test,  demonstration,  or 
inspection  (where  the  verification  method  is  by  analysis),  accepted  values  for  physical 
constants,  and,  where  applicable,  validated  threat  data. 

d.  The  acceptance  verification  data: 

(1)  Verifies  that  each  delivered  hardware  product,  each  constituent  product  of  a  delivered 
hardware  product,  and  each  system  product  that  is  used  to  manufacture,  verify, 
integrate,  or  deploy  end  products  that  are  to  be  delivered  meets  each  of  its  requirements 
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(other  than  those  for  which  the  verification  method  is  analysis)  in  the  maintained, 
allocated  design  release,  and/or  product  configuration  baselines  in  accordance  with  the 
applicable  verification  method  or  verification  requirements. 

(2)  Confirms  that  each  hardware  component  and  integrated  assembly  has  been  found  free 
of  deficiencies  in  workmanship  and  materials  based  on  the  inspections  and  tests 
required  by  the  design  release  baseline. 

(3)  Verifies  that  each  software  element  and  operational  procedure  performs  the  intended 
actions  without  unexpected  effects  and  is  free  of  detectable  errors. 

(4)  Verifies  interoperability  of  all  elements  (hardware,  software,  and  operations). 

e.  The  product  configuration  baseline: 

(1)  Incorporates  the  validated,  approved,  and  maintained  design  release  baseline. 

(2)  Is  based  on  the  planning,  monitoring,  decisions,  and  control  processes. 

(3)  Is  formed  after  confirmation  of  qualification  that  each  product  design  satisfies  all 
functional  and  performance  requirements  and  constraints  in  the  current  allocated  and 
design  release  baselines. 

(4)  Is  formed  after  confirmation  that  as-built,  as-coded,  as-procured,  or  as-integrated 
product  that  has  been  verified  for  delivery  acceptance  as  required  herein  is  accurately 
reflected  in  the  baselines. 

(5)  Is  validated  based  on  objective  data  to  ensure  compliance  with  the  above  attributes. 

f.  See  Section  5. 1 . 10  for  attributes. 

3.2.8  Design  Solution  Validation 

The  contractor  shall  support  the  government’s  validation  of  the  evolving  physical  solution  and 
develop  the  associated  required  systems  engineering  products  with  the  product  attributes  specified  in 
this  document. 

3.2.8. 1  Required  Systems  Engineering  Products 

a.  System  Validation  Plan 

b.  System  Validation  Data 

3. 2. 8. 2  Required  Product  Attributes 

a.  The  System  Validation  Plan: 

(1)  Defines  in  detail  and  documents  the  validation  process  the  contractor  intends  to  follow 
pursuant  to  system  validation  to  ensure  that  the  system  meets  stakeholder  expectations. 
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(2)  Identifies  any  computers  and  other  resources  needed  for  such  efforts  as  well  as  any 
needed  government-furnished  equipment  (GFE)  and  government-furnished  information 
(GF1). 

(3)  Documents  a  plan  for  modeling  and  simulation  in  conjunction  with  the  validation 
effort,  including  human-in-the-loop  simulation  that  includes: 

(a)  The  appropriate  level  of  detail,  given  the  available  time  and  other  resources  as  well 
as  the  granularity  of  information  available  at  the  time. 

(b)  A  representation  of  all  physical  devices  that  have  been  identified  thus  far  in  the 
synthesis  step  of  the  systems  engineering  process. 

(4)  Is  refined  in  subsequent  iterations  of  the  design  effort. 

(5)  Utilizes  techniques,  as  appropriate,  such  as  structured  walk-throughs,  mock-ups, 
simulations,  and  operational  testing  to  ensure  that  the  system,  when  completed,  will 
satisfy  stakeholders’  requirements. 

(6)  Includes  plans  for  accomplishing  LYF  assessments,  including  a  mission  readiness  test, 
b.  System  Validation  Data: 

(1)  Confirms  that  the  system  (hardware  and  software)  as  built  satisfies  the  user’s  needs  and 
requirements. 

(2)  Confirms  that  the  system  fulfills  all  the  required  functions,  and  only  those  required 
functions,  in  an  operational  environment. 

(3)  Documents  any  discrepancies  between  the: 

(a)  Product  configuration  baseline  and  stakeholder  expectations. 

(b)  Specified  performance  and  the  performance  obtainable  by  the  physical  devices 
selected  for  the  system  or  its  components. 

(c)  The  LYF  test  characteristics  and  mission  characteristics. 

(4)  Includes  inputs  to  the  Operational  Safety,  Suitability,  and  Effectiveness/Space  Flight 
Worthiness  (OSS&E/SFW)  certification,  including  the  definition  of  interim  and  final 
SFW  objectives  based  on  certification  criteria  provided  by  the  government  and  the 
assessment  of  progress  to  meet  the  criteria. 

(5)  Includes  support  to  the  system  readiness  reviews  to  include  the  mission  readiness 
review,  flight  readiness  review,  and  the  postflight  reviews. 

(6)  Supports  IOT&E,  including: 

(a)  Inclusion  of  developer  support  in  the  planning  and  execution  of  IOT&E,  including 
definition  and  interfaces  with  operational  test  agencies. 
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(b)  Execution  of  IOT&E  scenarios  in  simulated  10T&E  environments  to  the  degree 
practical  during  DT&E. 

(c)  Delivery  of  verified  technical  manuals,  operating  procedures,  and  training 
programs  (or  requirements  for  any  training  not  to  be  performed  under  the  contract) 
for  operational  personnel  prior  to  the  start  of  IOT&E. 

(d)  Delivery  of  requirements  for  government -inventory  (common)  support  equipment 
in  time  for  its  availability  prior  to  the  start  of  IOT&E. 

(e)  Deployment  and  readiness  of  verified  system  operational  equipment  (including 
software)  and  developer-supplied  support  equipment. 

(f)  Delivery  of  developer-supplied  spares  prior  to  the  start  of  IOT&E. 

(7)  Includes  LYF  test  results,  discrepancies,  and  exceptions. 

3.2.9  Application  Across  the  Life  Cycle 

The  contractor  shall  integrate  its  systems  engineering  process  with  the  design  review  process 
specified  by  contract  (see  Table  3-1). 

Table  3-1.  Development  Stages  for  Increasing  Accuracy  and  Completeness  of  the  Program  Baselines 


Technical  Review 
or  Audit 

Required  Maturity  of  the  Baselines 

Requirements 

Allocated 

Design  Release 

Product 

Configuration 

Alternative 

Systems 

Review 

ASR 

Preliminary,  focus 
on  support  to  JCIDS 

Preliminary, 
focus  on  physical 
elements  that 
drive  cost,  risk, 
and  other 
considerations 

Preliminary  -  basis  for 
support  to  capability  needs 
process  and  for  concept 
refinement 

System 

Requirement 

Review 

SRR 

Draft  that  balances 
system  effec¬ 
tiveness,  cost, 
schedule,  risk,  and 
growth  potential 

Preliminary, 
focus  on  physical 
elements  that 
drive  risk  or  other 
considerations 

Preliminary  -  reflects 
concept  refinement  and 
basis  for  technology 
maturation  and  other  risk 
reduction 

System 

Functional 

Review 

SFR 

Approved  IAW  3.2.1 

Draft  that  bal¬ 
ances  system 
effectiveness, 
cost,  schedule, 
risk  and  growth 
potential 

Preliminary  -  basis  for 
technology  selection  and 
for  the  assessment  to 
support  requirements 
baseline  validation 

Software 
Requirements 
and  Architecture 
Review 

SAR 

Review  the  Software 
Architecture  and 
Functional 
Requirements 
Baseline  IAW  3.1.2, 
3.2.1,  &  3.2.2 

Approve  the 
Software 
Architecture  and 
Functional 
Requirements 
Baseline  IAW 

3.1.2  &  3.2.1- 

3.2.3 

Approve  the  Software 
Architecture,  Functional, 
and  Design  Baseline  IAW 

3. 2.4-3. 2. 8 
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Technical  Review 
or  Audit 

Required  Maturity  of  the  Baselines 

Requirements 

Allocated 

Design  Release 

Product 

Configuration 

Preliminary 

Design 

Review 

PDR 

Maintained 

Approved  IAW 
3.2.3 

Draft  -  basis  for 
assessment  to  support 
allocated  baseline 
validation 

Critical 

Design 

Review 

CDR 

Maintained 

Maintained 

Approved  IAW  3.2.4  build, 
buy,  code,  author,  and 
integrate  developmental 
system  products  for 
qualification 

Functional 

Configuration 

Audit 

FCA 

Maintained 

Maintained 

Maintained 

System 

Verification 

Review 

SVR 

Maintained 

Maintained 

Maintained 

Physical 

Configuration 

Audit 

PCA 

Maintained 

Maintained 

Approved  and 
subsequently 
maintained 
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4.  Detailed  Requirements 


This  section  describes  detailed  systems  engineering  system  analysis  and  control  activities  that  shall 
be  applied  to  a  specific  program  based  on  the  system  and  program  requirements.  Tailored  program- 
specific  requirements  will  be  specified  in  the  solicitations  and  invoked  by  the  contract. 

The  System  Analysis  and  Control  activity  functions  as  the  planner,  manager,  judge,  traffic  cop,  and 
secretary  of  the  process.  This  activity  identifies  the  work  to  be  performed  and  develops  schedules  and 
costs  estimates  for  the  effort.  It  coordinates  the  other  activities  and  ensures  that  all  are  operating  from 
the  same  set  of  agreements  and  design  iterations.  It  evaluates  the  outputs  of  the  other  activities  and 
conducts  independent  studies  to  determine  which  of  the  alternate  approaches  is  best  suited  to  the 
application.  It  determines  when  results  of  one  activity  require  the  action  of  another  activity  and 
directs  the  action  to  be  performed.  It  documents  the  results  of  analyses  and  studies,  maintains  control 
of  the  evolving  configuration,  and  measures  and  reports  progress  [2] . 

The  system  analysis  and  control  activity  is  essential  to  effectively  perform  cross  functional  and 
organizational  integration  and  manage  and  control  the  engineering  efforts.  System  Analysis  and 
Control  is  an  integral  component  of  the  systems  engineering  process  depicted  in  Figures  3-1  and  3-3. 

The  analysis  and  control  activity  supports  and  complements  the  overall  program  monitoring  and 
control  activity. 

4.1  System  Analysis 

System  Analysis  includes  the  broad  range  of  assessments,  trades,  and  analyses  performed  over  the 
entire  life  cycle  of  a  system.  Contractors  shall  determine  and  perform  system  analyses  as  necessary  to 
determine  balanced  technical  solutions  pertaining  to  system  concepts,  technologies,  requirements,  and 
designs  of  a  system  and  its  components. 

The  contractor  shall: 

a.  Determine  which  analyses  are  required  to  meet  contractual  requirements,  objectives, 
applicable  standards,  engineering  practices,  and  data  item  descriptions  that  apply. 

b.  Determine  and  define  each  analysis  methodology  applying  the  attributes  listed  here  and  the 
specific  analytical  attributes  and  guidance  provided  in  the  subsections  below. 

(1)  Define  the  analytical  tasks  to  be  performed. 

(2)  Plan  analysis  such  that  their  performance  is  timed  to  provide  optimal  benefit  to  support 
other  required  analyses  and  trades  as  well  as  system  and  program  design,  production, 
and  test  decisions. 

(3)  Retain  analysis  results  in  the  decision  and  verification  databases. 

(4)  Periodically  validate  models  used  to  support  the  analysis.  Ensure  that  model  inputs  and 
outputs  are  valid  and  the  model  structure,  formulations,  and  algorithms  are  correct  and 
current. 

c.  Perform  the  analysis  following  the  approved  method  or  procedure. 
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d.  Prepare  the  analysis  report. 

e.  Leverage  the  analytical  results  with  the  other  engineering  and  program  activities. 

4.1.1  Assessments  of  System  Effectiveness,  Cost,  Schedule,  and  Risk 

The  contractor  shall  assess  the  system  effectiveness,  life  cycle  costs,  schedule,  risk,  and  evolutionary 
growth  potential  for  each  tradeoff  following  each  iteration  of  the  systems  engineering  process,  and 
develop  the  associated  required  systems  engineering  products  with  the  product  attributes  specified  in 
this  document. 


4.1. 1.1 

a. 

b. 

c. 

d. 

e. 

f. 

4.1. 1.2 

a. 


Required  Products 

Documented  process  for  assessing  system  effectiveness,  cost,  schedule,  and  risk. 

Documented  system  effectiveness  assessments  and  reports. 

Documented  cost  assessments  and  reports. 

Documented  schedule  assessments  and  reports. 

Documented  risk  assessments  and  reports. 

Documented  critical  fault  risk  assessments  and  reports. 

Required  Product  Attributes 

The  documented  process: 

(1)  Integrates  the  system/cost  effectiveness  analysis  and  assessment  tasks  into  the  systems 
engineering  process  to  support  development  of  life  cycle  balanced  products  and 
processes. 

(2)  Identifies  for  each  assessment  to  be  performed: 

(a)  The  tools,  source  data,  assumptions,  methodology,  and  development 
tools/environments  used. 

(b)  Quantified  objectives  and  goals. 

(c)  Measurements,  measurement  objectives,  and  analyses  activities  and  how  they 
correlate  with  required  capabilities,  system  technical  requirements,  and  constraints. 

(d)  The  elements  of  performance,  cost,  schedule,  and  risk  that  could  be  affected  by  the 
factors  considered  in  each  tradeoff  required  by  the  physical  solution  verification 
process. 


24 


b.  Each  assessment  of  system  effectiveness: 

(1)  Considers  parameters  that  encapsulate  the  capability  needed  as  well  as  the  engineering 
specialty  functions  in  selecting  the  elements  most  affected  by  the  factors  considered  in 
a  tradeoff. 

(2)  Surfaces  deficiencies  for  key  performance  parameters  (KPPs)  and  ensures  that  the 
traceability  between  the  MOEs,  MOPs,  KPPs,  and  TPMs  is  maintained. 

(3)  Is  based  on,  and  linked  to,  quantitative  test,  demonstration  or  inspection  data, 
applicable  handbook  data;  analysis  and  verification  data;  or  OT&E  data  when  it 
becomes  available. 

(4)  Utilizes  effectiveness  models,  including  simulations,  when  they  contribute  to  the 
decision  process. 

(5)  Is  based  on  prototype  or  developed  system  hardware  and  software  embedded  in  the 
analysis  when  that  balances  cost,  schedule,  and  risk. 

(6)  Compares  the  applicable  elements  of  the  integrated  architecture  for  interoperability  to 
the  Defense  Information  Standards  Registry  (D1SR)  and  all  other  intcrnal/cxtcrnal 
interface  issues. 

(7)  Includes  environmental  analysis  and  impact. 

c.  Each  assessment  of  cost: 

(1)  Is  based  to  the  extent  applicable  on  quantitative  historical  cost  data. 

(2)  Applies  a  methodology  that  is  accepted  industrywide. 

(3)  Is  based  on  relationships  for  which  the  assessment  documentation  includes  the 
derivation  when  new  approaches  or  technologies  require  new  cost  estimating 
relationships  or  procedures. 

(4)  Employs  simulation  where  cost  effective. 

(5)  Includes  established  design-to-cost  targets,  a  current  estimate  of  these  costs,  and  known 
uncertainties  in  these  costs. 

(6)  Addresses  cost  and  schedule  risk. 

(7)  Is  conducted  and  updated  as  designated  in  the  contract  to  support  decisions, 
assessments  of  system  cost  effectiveness,  and  tradeoff  studies  to: 

(a)  Identify  the  sunk  costs  to  the  extent  required  for  the  specific  cost  assessment. 

(b)  Provide  an  estimate  of  the  remaining  development,  production,  operations  and 
support  (O&S),  and  life  cycle  costs  for  the  proposed  system  concept  to  include  new 
or  modified  government  facilities. 
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(c)  Demonstrate  that  the  system  concept  and  development  plans  for  completing 
development — including  any  plans  for  new  parts,  materials,  or  processes,  new  or 
modified  facilities,  or  other  new  or  modified  resources — are  affordable  and  meet 
the  program  schedule  requirements  at  acceptable  risk. 

(d)  Identify  the  economic  consequences  of  solution  alternatives. 

(e)  Develop  the  requisite  cost  information  to  support  decisions  on  alternative  people, 
product,  and  process  solutions  and  risk  assessments. 

d.  Each  assessment  of  schedule: 

(1)  Is  based  on  quantitative  historical  time  spans  where  available  and  applicable. 

(2)  Includes  any  necessary  assumptions  explicitly  stated  and  applied  so  that  consistency  is 
achieved  among  assessments. 

e.  Each  assessment  of  risk: 

(1)  Develops  objective  text  descriptions  identifying  each  risk. 

(2)  Identifies  why  and  when  each  risk  might  occur. 

(3)  Specifies  the  likelihood  and  possible  consequences. 

(4)  Proposes  corrective  actions  to  mitigate  the  risk. 

(5)  Develops  a  plan/metrics  to  monitor  risks  and  corrective  action  plans. 

f.  Each  assessment  of  critical  fault  risk  (CFR): 

(1)  Includes  all  first-time  events  and  mission  critical  activities  not  allocated  to  a  LYF  test 
as  part  of  program  test  plans. 

(2)  Includes  LYF  test  exceptions  that  are  correlated  to  the  mission  critical  fault  analysis 
(MCFA). 

(3)  Each  CFR  shall  be  considered  to  be  50%  probable  (either  potential  flaw  exists  or  not). 

4.1.2  Tradeoff  Analysis 

The  contractor  shall  identify,  organize,  plan,  and  conduct  tradeoffs  to  compare  the  capability  or 
effectiveness,  life  cycle  cost,  schedule,  and  risk  implications  of  each  promising  alternative,  and 
develop  the  associated  required  systems  engineering  products  with  the  product  attributes  specified  in 
this  document. 

4.1. 2.1  Required  System  Engineering  Products 

a.  Documented  tradeoff  analyses. 
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4.1. 2. 2  Required  Product  Attributes 


a.  Documented  tradeoff  analyses  include: 

(1)  The  objective  comparative  assessments  of  system  effectiveness,  life  cycle  cost, 
schedule,  risk,  and  evolutionary  growth  implications  for  each  feasible  alternative 
requirement,  functional  decomposition,  allocation,  and/or  design  selection. 

(2)  Standards  for  the  integrated  architecture  that  assure  interoperability. 

(3)  Plans  and  results  that  are  documented  and  included  in  the  decision  database. 

4.1.3  Decision  Analysis 

The  contractor  shall  implement  the  actions  necessary  to  evaluate  and  select  from  alternatives  in  order 
to  develop  the  baselines,  functional  architecture,  and  other  systems  engineering  products  required 
herein  to  achieve  approval  of  the  baselines,  and  to  maintain  the  baselines  and  functional  architecture 
over  the  system  life  cycle. 

4.1. 3.1  Required  System  Engineering  Products 

a.  Documented  and  implemented  decisions 

b.  Maintained  baselines  and  functional  architecture 

4.1. 3. 2  Required  Product  Attributes 

a.  Documented  and  implemented  decisions  are: 

(1)  Included  in  the  decision  database  for  each  iteration  and  each  design  selection  toward 
achieving  the  baseline  attributes. 

(2)  Explicitly  related  to  the  tradeoffs  and  assessments  conducted  or  other  objective 
analyses  or  monitoring  data. 

(3)  Captured  in  terms  of  proposed  baselines  or  functional  architecture  or  updates  or 
changes  thereto,  corrective  action  plans,  and/or  updates  to  the  plans  and  monitoring 
devices  required  above. 

b.  Maintained  baselines  and  functional  architecture  includes: 

(1)  The  assessment  of  each  proposed  change  to  a  baseline  or  the  functional  architecture  to 
determine: 

(a)  The  corresponding  impacts  to  the  other  baselines  or  the  functional  architecture. 

(b)  The  impacts  to  the  system  effectiveness  and  potential  for  growth  in  relation  to  the 
requirements  baseline. 
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(c)  The  impacts  to  both  total  program  life  cycle  and  instant  contract  cost,  schedule,  and 
risk. 

(2)  Relating  the  basis  for  the  proposed  change  to  these  assessments  to  determine  if  the 
proposed  change  is  justified. 

(3)  The  two-way  traceability  from  the  systems  engineering  program  foundation  through  the 
baselines  and  functional  architecture  as  well  as  traceability  from  each  element  to  the 
supporting  analyses  and  assessments,  and  the  balance  between  system  effectiveness 
and  evolutionary  growth  potential  (explicitly)  to  avoid  the  potential  for  significant 
added  cost,  schedule,  or  risk  for  small  gains  in  effectiveness. 

(4)  Documentation  of  the  basis,  assessments,  justification,  agreements,  and  approvals  for 
each  change  in  the  decision  database. 

(5)  The  status  of  the  implementation  of  all  approved  changes  in  affected  system  and 
systems  engineering  products. 

4.1.4  Operational  Analysis  and  Assessment 

The  contractor  shall  conduct  operational  analyses  and  assessments  to  support  the  development  of 
people,  product,  and  process  solutions  necessary  to  satisfy  operational  requirements  for  system  end 
items. 

4.1. 4.1  Required  System  Engineering  Products 

Operational  analysis-related  tradeoffs  and  analyses  linked  to  the  system  engineering  process  iterations 
of  which  they  are  a  part  and  to  any  decisions  that  they  support  or  justify. 

4.1. 4.2  Required  Product  Attributes 

a.  Analyses  and  assessments  of  the  operational  use  of  alternative  solutions  addressing: 

(1)  How  solutions  will  be  used  to  accomplish  required  tasks  in  their  intended 
environments. 

(2)  Interfacing  systems  required  to  execute  operational  functions  in  the  intended  use 
environment. 

(3)  Joint  and  combined  operations. 

(4)  Modes  of  operational  deployment,  mission  phases,  and  mission  employment. 

b.  Includes  mission  operations-critical  characteristics  of  people,  product,  and  process  solutions 

and  their  risks  mission,  including  those  derived  from  mission  critical  flaws,  in  the  risk 

management  process. 
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4.1.5  Environmental  Analysis  and  Impact  Assessment 

Environmental  analysis  shall  be  performed  to  determine  the  impact  on  and  by  each  system  product 
and  process  alternative. 

4.1. 5.1  Required  System  Engineering  Products 

Environmental-related  tradeoffs  and  analyses  linked  to  the  system  engineering  process  iterations  of 
which  they  are  a  part  and  to  any  decisions  that  they  support  or  justify. 

4.1. 5.2  Required  Product  Attributes 

a.  Adheres  to  all  applicable  statutes  and  to  contractually  designated  hazardous  materials  lists. 

b.  Analyzes  factors  such  as  noise  pollution,  quantities,  and  types  of  hazardous  materials  used, 
hazardous  waste  disposal,  and  other  defined  environmental  requirements  as  applicable. 

c.  Defines  and  assesses  methods  to  mitigate  problems  and  impacts  identified  from  this  analysis. 

d.  Includes  the  results  of  these  assessments  into  effectiveness  analyses  as  well  as  system 
definition,  design,  and  verifications. 

e.  Documents  analysis  output  appropriate  to  the  acquisition  phase  and  use  in  conjunction  with 
cost  and  performance  analyses  outputs  to  support  acquisition  phase  exit  criteria. 

f.  Avoids  use  of  materials  that  present  a  known  hazard  to  the  environmental. 

g.  Includes  environment-critical  characteristics  of  people,  product,  and  process  solutions,  and 
their  risks  included  in  risk  management  process. 

4.1.6  Training  Analysis  and  Assessment 

The  contractor  shall  conduct  training  analyses  and  assessments  to  support  development  of  people, 
product,  and  process  solutions  to  train  users  of  system  end  items. 

4.1. 6.1  Required  System  Engineering  Products 

Training-related  tradeoffs  and  analyses  linked  to  the  System  Engineering  Process  iterations  of  which 
they  are  a  part  and  to  any  decisions  that  they  support  or  justify. 

4.1. 6. 2  Required  Product  Attributes 

a.  Includes  the  development  of  personnel  capabilities  and  proficiencies  to  accomplish  tasks  at 
any  point  in  the  system  life  cycle  to  the  level  they  are  tasked. 

b.  Considers  both  initial  and  follow-on  training  necessary  to  execute  required  tasks  associated 
with  system  end-item  use. 

c.  Includes  training-critical  characteristics  of  people,  product,  and  process  solutions  and  their 
risks  in  risk  management  process. 
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4.1.7  Transition  (Deployment)  Analysis  and  Assessment 


The  contractor  shall  conduct  deployment  analyses  and  assessments  to  support  the  development  of 
people,  product,  and  process  solutions  necessary  to  deploy  system  end  items  and  develop  the 
associated  required  systems  engineering  products  with  the  product  attributes  specified  in  this 
document. 

4. 1.7.1  Required  System  Engineering  Products 

a.  Tradeoffs  and  other  analyses  that  are  linked  in  the  decision  database  to  the  System 

Engineering  Process  iterations  of  which  they  are  a  part  and  to  any  decisions  that  they  support 
or  justify. 

4. 1.7.2  Required  Product  Attributes 

a.  Deployment  analyses  and  assessments  address: 

(1)  Factors  for  site/host  selection,  activation/installation,  field  assembly,  and  checkout 
requirements,  including  identification  of  site-unique  hazard  classification  and  explosive 
ordnance  disposal  requirements. 

(2)  Operational  and  maintenance  facilities  and  equipment  requirements. 

(3)  Compatibility  with  existing  infrastructure  (e.g.,  computer/communication  systems). 

(4)  Determination  of  environmental  impacts  and  constraints  (environment  impacts  on  the 
system  and  system  impacts  on  the  environment)  at  deployment  sites  as  defined  by  the 
environmental  analysis  and  impact  assessment  task. 

(5)  Training  items  and  personnel. 

(6)  Provisioning  and  spares. 

(7)  Packaging,  handling,  storage,  and  transportation. 

(8)  Site  transition  requirements. 

(9)  Deployment-critical  characteristics  of  people,  product,  and  process  solutions  to  be 
included  in  risk  management  efforts. 

4.1 .8  Supportability  Analysis  and  Assessment 

The  contractor  shall  conduct  supportability  analyses  and  assessments  to  assist  in  the  development  of 
people,  product,  and  process  solutions  to  support  system  end  items  over  the  system  life  cycle. 

4.1. 8.1  Required  System  Engineering  Products 

Supportability-related  tradeoffs  and  analyses  linked  to  the  System  Engineering  Process  iterations  of 
which  they  are  a  part  and  to  any  decisions  that  they  support  or  justify. 
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4.1. 8. 2  Required  Product  Attributes 

a.  Identifies  all  contractually  specified  levels  of  operation,  maintenance,  and  training  for  system 
end  items. 

b.  Identifies  and  integrates  into  the  SE  process  supportability-related  factors  to  ensure  that 
system  end  items  satisfy  their  intended  uses. 

c.  Develops  a  complete  and  integrated  support  structure  (people,  products,  and  processes)  across 
the  system  life  cycle. 

d.  Specifies  support  resource  needs,  including  parts,  people,  facilities,  and  materials. 

e.  Includes  supportability-critical  characteristics  of  people,  product,  and  process  solutions  and 
their  risks  included  in  the  risk  management  process. 

4.1.9  Disposal  Analysis  and  Assessment 

The  contractor  shall  conduct  disposal  analyses  and  assessments  to  support  development  of  people, 

product,  and  process  solutions  to  dispose  of  products  and  by-products. 

4.1. 9.1  Required  System  Engineering  Products 

Disposal-related  tradeoffs  and  other  analyses  to  the  System  Engineering  Process  iterations  of  which 

they  are  a  part  and  to  any  decisions  that  they  support  or  justify. 

4.1. 9. 2  Required  Product  Attributes 

a.  Identifies  environmental  factors  for  process  waste  and  output  as  well  as  used  products  and 
components. 

b.  Evaluates  effective  disposal  methods  for  system  parts  and  materials  and  requirements  for  new 
or  modified  methods,  including  storage,  dismantling,  demilitarization,  reusing,  recycling,  and 
destruction. 

c.  Identifies  costs,  sites,  responsible  agencies,  handling  and  shipping,  supporting  items,  and 
applicable  federal,  state,  local,  and  host  nation  regulations  as  factors. 

d.  Includes  disposal-critical  characteristics  of  people,  product,  and  process  solutions  and  their 
risks  in  the  risk  management  process. 

4.1.10  Mission  Critical  Fault  Analysis  (MCFA) 

The  contractor  shall  conduct  a  mission  critical  fault  analysis  to  identify  the  mission  critical  failures 

for  each  mission  phase  and  the  fault  conditions  that  led  to  each  failure. 

4.1.10.1  Required  System  Engineering  Products 

a.  Mission  critical  fault  analysis 
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4.1.10.2  Required  System  Engineering  Attributes 

a.  Mission  failures  are  identified  by  a  team  representing  all  mission  elements  and  technical 
disciplines. 

(1)  Each  potential  mission  failure  will  be  populated  with  all  single  fault  paths  to  that  failure. 

(a)  Single  fault  paths  include  those  that  involve  mismatches  between  two  items  or 
elements  (e.g.,  race  conditions,  counting  strategy,  or  engineering  units). 

b.  Each  mission  failure  analysis  will  be  documented  (e.g.,  in  an  analytical  tool  such  as  master 
logic  diagram,  fault  tree,  event  tree,  or  Ishikawa  diagram). 

c.  MCFA  will  be  updated  as  necessary  to  reflect  changes  in  operations,  hardware  design,  or 
software  design. 

4.2  Systems  Control 

4.2.1  Management  and  Control  of  the  Systems  Engineering  Process 

The  contractor  shall  plan,  execute,  and  control  the  engineering  efforts.  In  addition,  the  contractor 
shall  ensure  appropriate  flowdown  of  requirements  and  technical  management  of  subcontractors  and 
vendors. 

Typical  control  activities  are  illustrated  in  Figure  4-1.  The  control  activities  are  executed  according  to 
the  planning  and  include  monitoring  (measurements/metrics  programs,  technical  reviews  and  audits, 
corrective  action  programs),  interface  management/control,  risk  management,  configuration 
management,  data  management,  decisionmaking,  architecture  management,  and  requirements 
management. 

4.2. 1.1  Planning 

The  contractor  shall  plan  all  aspects  of  the  systems  engineering  effort. 
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Figure  4-1.  Engineering  control  activities. 

4.2. 1.1.1  Required  System  Engineering  Products 

a.  Contract  Work  Breakdown  Structure  (CWBS) 

b.  The  systems  engineering  accomplishments,  accomplishment  criteria,  and  narrative  in  the 
integrated  master  plan  (IMP);  tasks  in  the  integrated  master  schedule  (IMS);  and  work 
packages  in  the  earned  value  management  system  (EVMS),  and  other  specific  plans  (such  as 
tradeoff  plans)  as  may  be  needed  to  achieve  the  attributes  required  above. 

4.2.1 .1 .2  Required  Product  Attributes 

a.  The  CWBS  is  consistent  with  the  evolving  physical  hierarchy  and  is  maintained  and  applied 
to  plan  and  monitor  all  work  carried  out  under  the  contract. 

b.  The  IMP,  IMS,  EVMS,  and  other  specific  plans  as  needed: 

(1)  Reflect  all  technical  execution  and  management  efforts. 

(2)  Are  organized  to  support  orderly  decisionmaking  (such  as  in  a  decision  tree). 

(3)  Establish  schedules  consistent  with  all  other  program  plans  for  the  completion  of 
TBDs,  formalization  of  TBSs,  or  resolution  of  TBRs  in  approved  baselines. 
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4.2. 1.2  Monitoring 

The  contractor  shall  monitor  the  progress  against  all  planning  to: 

a.  Identify  decisions  that  are  initially  necessary  to  provide  the  minimum  capabilities  needed  and 
to  satisfy  the  requirements  baseline. 

b.  Validate,  approve,  and  maintain  each  baseline  and  the  functional  architecture. 

c.  Maintain  the  design  balanced  with  respect  to  system  effectiveness,  cost,  schedule,  risk,  and 
potential  for  evolutionary  growth. 

d.  Monitor/mitigate  each  risk. 

4. 2. 1.2.1  Required  System  Engineering  Products 

a.  Comparison  of  all  systems  engineering  assessments  in  the  decision  database  to  the  initial 
plans,  the  results  of  each  iteration  for  which  it  is  a  part  to  include  tradeoffs  and  other 
assessments,  the  decisions  made  and  their  justification,  and  the  actions  taken. 

4. 2. 1.2. 2  Required  Product  Attributes 

a.  Each  documented  assessment  includes,  but  is  not  limited  to: 

( 1 )  Status  of  system  effectiveness,  schedule,  life  cycle  cost,  risk  (to  include  the  status  of 
the  risks  on  the  watch  list),  including  progress  against  the  plans. 

(2)  Assessments  of  the  verification  and  validation  data  (when  developed  products  are 
available)  to  ensure  effective  identification,  disposition,  and  control  of  deficiencies  and 
nonconformances. 

(3)  Assessments  of  change  control  implementation  to  identify  instances  when  baselines  are 
not  in  consonance  or  when  baselines  or  products  are  not  in  compliance  with  the  change 
control  actions. 

(4)  All  risks,  including  those  identified  by  the  assessments,  which  are  designated  to  be 
monitored  as  part  or  all  of  the  selected  mitigation  approach. 

(5)  The  TPMs,  metrics,  and/or  renewed  risk  assessments  for  monitoring  each  risk. 

(6)  Metrics  and  select  technical  parameters  for  tracking  that  are  critical  indicators  of 
technical  progress  and  achievement  and  include  system  parameters,  configuration  item 
(Cl)  parameters,  or  both. 

(7)  The  critical  fault  risk  list: 

(a)  Includes  critical  fault  risks  associated  with  decisions  to  not  perform  LYF  tests  and 
with  LYF  test  exception  faults  that  cannot  be  mitigated  within  resources  allocated 
to  for  test/repair/rework/retest. 
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(b)  Elevates  to  program  risk  management  any  LYF  test  necessary  to  validate  the 
executability  of  a  first-time  event,  mission  critical  activity,  or  mission  sequence 
that  cannot  be  performed  within  element  test  resources. 

4. 2. 1.3  Interface  Management 

The  contractor  shall  manage  the  internal  interfaces  within  their  contractual  responsibility,  support 
activities  established  to  ensure  that  external  interfaces  are  managed  and  controlled,  and  develop  the 
associated  required  systems  engineering  products  with  the  product  attributes  specified  in  this 
document. 

4. 2. 1.3.1  Required  System  Engineering  Products 

a.  Interface  definition  documentation. 

b.  Operational  concepts  documentations. 

4. 2. 1.3. 2  Required  Product  Attributes 

a.  The  interface  definition  documentation,  for  each  system  engineering  iteration: 

( 1 )  Establishes,  coordinates,  and  maintains  interface  controls  for  interface  requirements, 
documents,  and  drawings,  and  includes  all  applicable  contractor,  vendor,  and 
subcontractor  contract  items  and  government-furnished  equipment,  computer 
programs,  facilities,  and  data. 

(2)  Controls  interfaces  to  ensure  accountability  and  timely  dissemination  of  changes. 

(3)  Captures  all  changes  to  the  internal  and  external  interfaces  in  the  decision  database. 

(4)  Ensures  that  all  interface  requirements  are  verified. 

b.  The  operational  concepts  documentation,  for  each  systems  engineering  iteration: 

( 1 )  Establishes,  coordinates,  and  maintains  planned  methodologies  for  executing  each 
mission  phase  and  constituent  activities;  interactions  and  transactions  between 
operational  elements;  constraints  and  considerations  for  the  execution  of  all  mission 
activities. 

(2)  Controls  operational  and  data  interactions  and  transactions  to  ensure  accountability  and 
timely  dissemination  of  changes. 

(3)  Captures  in  the  decision  database  all  changes  to  the  constraints  and  considerations 
documented  for  mission  operational  data  interactions  and  transactions. 

(4)  Ensures  that  all  mission  operational  data  interactions  and  transactions  are  validated  in 
LYF  tests. 
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4.2. 1.4 


Risk  Management 


The  contractor  shall  establish  and  implement  a  risk  management  program  and  develop  the  associated 
required  systems  engineering  products  with  the  product  attributes  specified  in  this  document. 

4. 2. 1.4.1  Required  Products 

a.  Risk  Management  Plan. 

b.  Risk  Watch  List. 

4. 2. 1.4. 1.1  Required  Product  Attributes 

a.  The  Risk  Management  Plan: 

(1)  Specifies  a  process  that  documents  risks  (including  all  associated  assumptions), 
evaluates  mitigation  approaches,  and  assesses,  monitors,  and  documents  risks 
associated  with  system  requirements. 

(2)  Includes  program  risk  assessment  as  it  applies  to  identifying,  analyzing,  and  ranking 
risks  associated  with  system  requirements  for  completeness  and  adequacy. 

(3)  Assesses  products,  processes  (e.g.,  process  variability),  and  their  interrelationships. 

(4)  Includes  risks  associated  with  contractually  identified  variations,  uncertainties,  and 
evolutions  in  system  environments. 

(5)  Identifies  potential  sources  of  technical  risk,  including  critical  parameters  that  can  be 
risk  drivers. 

(6)  Quantifies  risks,  including  risk  levels,  in  terms  of  the  likelihood  of  occurrence  and  the 
severity  of  their  impacts  on  cost  (including  life  cycle  costs),  schedule,  and 
performance.  Includes  design,  cost,  and  schedule  uncertainties  and  sensitivity  to 
program,  product,  and  process  assumptions. 

(7)  Includes  the  activities  and  criteria  for  identifying,  assessing,  validating,  and  transition¬ 
ing  critical  technologies  from  technology  development  and  demonstration  programs, 
including  commercially  developed  technologies. 

(8)  Includes  technology  readiness  level  (TRL)  in  performance,  affordability,  and  life  cycle 
processes  in  the  criteria. 

(9)  Addresses  how  technology  refresh  will  be  accomplished. 

(10)  Defines  sensitivity  of  interrelated  risks. 

(11)  Includes  alternative  approaches  to  handle  moderate  and  high  risks. 

(12)  Documents  actions  to  avoid,  control,  or  assume  each  risk. 
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(13)  Includes  an  established  process  for  continued  identification  of  risks  throughout  the 
program  life  cycle. 

(14)  Includes  the  evaluation  of  risk  factors  as  a  part  of  decisionmaking,  including  the 
selection  of  specification  requirements,  and  design  and  solution  alternatives. 

b.  The  Risk  Watch  List: 


(1)  Includes  all  risks,  including  those  identified  by  assessments  that  are  designated  to  be 
monitored  as  part  or  all  of  the  selected  mitigation  approach. 

(2)  Identifies  the  technical  performance  measures  (TPMs),  metrics,  and/or  renewed  risk 
assessments  for  monitoring  each  risk,  describe  the  methodology,  tools,  and  schedule 
for  assessing  each,  and  links  each  to  the  CWBS  entry  for  the  applicable  product. 


(3)  Is  assessed  for  each  integrated  assessment  and  at  other  times  called  for  by  the  planning 
required  to  provide  timely  alerts  of  the  need  for  risk  mitigation  actions. 


4.2. 1.5  Configuration  Management 


The  contractor  shall,  consistent  with  other  configuration  management  requirements  of  the  contract, 
manage  the  changes  to  and  maintain  the  baselines  and  functional  architecture  over  the  life  cycle  of  the 
system,  and  develop  the  associated  required  systems  engineering  products  with  the  product  attributes 
specified  in  this  document. 

4.2. 1.5.1  Required  System  Engineering  Products 


a.  Documentation  of  configuration  management  process. 


b.  Assessments  of  change  control  implementation. 

4.2. 1.5.2  Required  Product  Attributes 


a.  The  documented  configuration  management  process: 

(1)  Is  based  on  a  current  and  active  government  or  industry  standard,  or  other  specified  by 
contract. 

(2)  Provides  total  life  cycle  configuration  management  planning  for  the  program  and 
manages  the  implementation  of  that  planning. 

(3)  Includes  configuration  identification,  which  includes  establishment  of  a  structure  for 
products  and  product  configuration. 

(4)  Includes  configuration  change  control,  which  ensures  that  changes  to  a  configuration 
baseline  are  properly  identified,  recorded,  evaluated,  approved  or  disapproved,  and 
incorporated  and  verified,  as  appropriate. 
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(5)  Includes  configuration  status  accounting,  which  manages  the  capture  and  maintenance 
of  product  configuration  information  necessary  to  account  for  the  configuration  of  a 
product  throughout  the  product  life  cycle. 

(6)  Includes  configuration  verification  and  audit,  which  establishes  that  the  performance 
and  functional  requirements  defined  in  the  product  definition  information  have  been 
achieved  by  the  design  and  that  the  design  has  been  accurately  documented  in  the 
product  definition  information. 

b.  Assessments  of  change  control  implementation: 

(1)  Include  the  decisions  and  change  control  actions  to  develop  the  baselines  and  the 
functional  architecture. 

(2)  Include  configuration  control,  including  the  systematic  proposal,  justification, 
evaluation,  coordination,  approval,  or  disapproval  of  all  proposed  changes  to  the 
baselines  and  functional  architecture. 

(3)  Explicitly  assess  each  proposed  change  to  a  baseline  or  functional  architecture  to 
determine: 

(a)  The  corresponding  impacts  to  the  other  baselines  and  the  functional  architecture. 

(b)  The  impacts  to  the  system  effectiveness  and  potential  for  growth  in  relation  to  the 
requirements  baseline  or  the  needed  capability  and  in  relation  to  both  total  program 
and  instant  contract  cost,  schedule,  and  risk. 

(4)  Assess  risks  for  products,  processes  (e.g.,  process  variability),  and  their 
interrelationships,  including  contractually  identified  variations,  uncertainties,  and 
evolutions  in  system  environments. 

(5)  Plan  and  conduct  new  verifications,  and  record  the  results  in  the  decision  database. 

(6)  Document  the  basis,  assessments,  justification,  agreements,  and  approvals  for  each 
change  in  the  decision  database. 

(7)  Monitor  the  status  of  implementing  all  approved  changes. 

4.2. 1.6  Data  Management 

The  contractor  shall  establish  and  maintain  a  data  management  system,  and  develop  the  associated 

required  systems  engineering  products  with  the  product  attributes  specified  in  this  document. 

4.2. 1.6.1  Required  System  Engineering  Products 

a.  Data  products  as  required  by  the  contract  and  to  support  the  program. 

4.2. 1.6.2  Required  Product  Attributes 

a.  The  data  products: 
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(1) 

(2) 

(3) 

(4) 

(5) 


Capture  and  organize  all  inputs  as  well  as  current,  intermediate,  and  final  outputs. 

Provide  traceability  and  correlation  (relationship)  of  data  between  requirements, 
designs,  solutions,  decisions,  and  rationale. 

Document  engineering  decisions,  including  procedures,  methods,  results,  and  analyses. 
Are  responsive  to  established  configuration  management  procedure. 

Function  as  a  reference  and  support  tool  for  the  systems  engineering  effort. 

Technical  Management  of  Subcontractors/Vendors 


The  developer  shall  flow  the  systems  engineering  requirements  defined  herein  as  tailored  per  contract 
as  well  as  the  applicable  technical  requirements  in  the  allocated  baseline,  down  to  any  subcontractor 
or  supplier  who  will  conduct  development  tasks  under  the  contract  or  subcontract,  and  develop  the 
associated  required  systems  engineering  products  with  the  product  attributes  specified  in  this 
document. 


The  developer  shall  establish  effective  subcontractor/vendor  contracts,  monitor,  make  decisions 
regarding,  and  control  subcontractor  activity  to  comply  with  the  requirements  herein  with  the  same 
vigor  and  effectiveness  as  for  activity  within  the  developer’s  company. 

4.3  Specialty  Engineering  Analysis  and  Control  Contributions 

The  contractor  shall,  for  each  specialty  area  listed  below: 

a.  Ensure  that  the  following  specialty  functions  and  disciplines  are  incorporated  into  the  systems 
engineering  process. 

b.  Establish  a  documented  valid/approved  process  (including  but  not  limited  to  applicable 
corporate  process,  military  standards,  military  handbooks,  NSS/industry  standard  processes) 
that  is  comprehensive  and  responsive  to  the  system/end-user  requirements  for  each  specialty 
engineering  area  being  integrated  into  the  systems  engineering  effort. 

c.  Include  specialty  engineering  requirements  in  the  requirements  analysis,  functional 
analysis/allocation,  synthesis,  and  systems  analysis  and  control. 

d.  Include  their  impact  in  system  life  cycle  cost  estimates  as  well  as  in  total  system 
performance/reliability  assessments. 

4.3.1  Parts,  Materials,  and  Processes  (PMP) 

a.  Detailed  environmental  parameters  are  defined/derived  that  impact  parts  performance. 

b.  Parts/materials  engineering/design  requirements  are  allocated,  baselined,  and  traced  to 
system-level  performance  requirements,  including  risk  assessments. 

c.  Functional  parameters  are  baselined  and  captured  in  detailed  technicaFprocurement 
specifications. 
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d.  Technology  development  plans  are  executed  and  technology  readiness  levels  demonstrate 
products/technology  suitable  for  system  application  and  support  program  development 
schedules. 

e.  Qualified  sources  of  supply  and  industrial  base  assessment  are  addressed. 

f.  Space  systems  radiation-hardening  design  solutions  are  established. 

4.3.2  Structures 

a.  Detailed  performance  and  technical  requirements  for  each  structural  system,  subsystem,  and 
component  are  defined,  allocated,  and  traced  to  system  requirements. 

b.  Structural  design  specifications  comply  with  requirements  and  NSS  industry  practice. 

c.  Verification  methods  for  each  structural  requirement  are  defined. 

d.  Structural  requirements  correlation  with  military  and  other  government  documents,  including 
standards,  specifications,  handbooks,  guidelines,  and  Commander’s  policies,  are  presented. 

e.  Technical  risk  mitigation  approaches  are  defined. 

f.  Trade  studies  and  detailed  analyses  support  structural  design  solutions. 

g.  Analysis  tools  and  techniques  are  consistent  with  NSS  industry  practice. 

h.  Design  qualification  methods  adequately  define  approach  to  demonstrate  structural  adequacy. 

i.  Quality  assurance  methodology  ensures  delivery  of  high-quality  product. 

4.3.3  Manufacturing 

a.  Producibility  engineering  principles  and  practices  are  integrated  into  the  design  process. 

b.  Manufacturing  methods  and  processes  required  to  build  the  design  are  qualified  and 
demonstrated  to  meet  system  performance  requirements  and  reliability. 

c.  Manufacturing  analyses  include  producibility  analyses  and  manufacturing  and  production 
inputs  to  system  effectiveness,  tradeoff  studies,  and  life  cycle  cost  analyses. 

d.  Alternative  designs  and  capabilities  of  manufacturing  are  evaluated. 

e.  Long-lead-time  items,  material  source  limitations,  availability  of  materials  and  manufacturing 
resources,  and  production  cost  are  identified,  assessed,  and  documented. 

f.  Manufacturing-critical  characteristics  of  people,  product,  and  process  solutions  and  their  risks 
are  identified. 

g.  Tooling  and  test  equipment  strategies  and  requirements  are  defined. 
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h.  Manufacturing  and  producibility  requirements  and  constraints  are  defined. 

i.  Items  are  producible  and  stable  manufacturing  processes  are  in  place  to  reduce  risk, 
manufacturing  cost,  lead  time,  and  cycle  time,  and  to  minimize  use  of  strategic  and  critical 
materials. 

j.  As  part  of  system  design,  manufacturing  methods,  processes,  and  process  controls  have  been 
defined,  evaluated,  and  selected,  based  on  total  system  cost,  schedule,  performance,  and  risk. 

k.  Product  design  has  stabilized,  the  manufacturing  processes  and  process  controls  have  been 
proven,  and  production  facilities,  equipment,  capability,  and  capacity  are  in  place  (or  are 
about  to  be  established)  to  support  the  approved  schedule. 

4.3.4  Quality  Assurance 

a.  Qualified  inspection/test  processes  demonstrating  effectiveness. 

b.  Capable  processes  are  established  for: 

( 1 )  Monitoring  and  control  of  critical  processes  and  product  variation. 

(2)  Establishment  of  mechanisms  for  feedback  of  field  performance. 

(3)  Implementation  of  an  effective  root-cause  analysis  and  corrective  action  system; 
continuous  process  improvement. 

(4)  Disciplined  control  over  the  design,  procurement,  manufacturing,  integration,  and  test 
processes. 

c.  Quality  assurance  schedules  are  established  to  concurrently  support  procurement, 
manufacturing,  integration,  and  test  processes. 

d.  Quality  assurance  policies  and  procedures  are  in  place  to  manage  internal  and  external  pro¬ 
duction  sources. 

4.3.5  Test 

a.  Design  test  requirements  are  defined,  allocated,  and  traced  to  system-level  requirements, 
including  risk  assessments. 

b.  Integrated  test  plans,  procedures,  and  schedules  are  defined  and  are  consistent  with  and 
integrated  with  program  schedules. 

c.  All  system  components  (hardware,  software,  and  human  interfaces)  critical  to  verifying 
achievement/demonstration  of  system  technology  requirement  are  addressed. 

d.  Test  tools,  test  equipment  (including  special  test  equipment )/software,  diagnostics  software, 
modeling  and  simulation  requirements  are  defined,  allocated,  and  traced  to  system 
components. 
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e.  Test  and  verification  methodologies  and  criteria  for  data  gathering,  reduction,  and  analysis 
are  defined  and  documented. 

f.  Data  acquisition  requirements,  documentation,  methods  of  analysis,  and  pass-fail  criteria  are 
defined  and  documented. 

g.  Training  and  certification  requirements  are  identified  and  programmed  to  meet  test  and 
evaluation  schedules. 

h.  An  approach  to  provide  test  support  and  documentation  to  design  changes  on  hardware  and 
software  is  developed. 

4.3.6  Survivability 

a.  System-level  survivability  requirements  are  defined,  allocated,  baselined,  and  traced  to  the 
system-level  requirements. 

b.  System  survivability  attributes  and  mission  objectives  evolved  into  a  set  of  system-level 
survivability  requirements. 

c.  An  approach  for  verification  of  system-level  survivability/operability  requirements  is 
identified. 

d.  Test  facilities  capable  of  simulating  threat  environments  are  identified. 

e.  Threat  assessments  and  analysis  are  conducted,  defining  categories  of  the  expected  threats 
(i.e.,  nuclear,  biological,  terrorism,  etc.)  and  their  likelihood  of  occurrence. 

f.  Threats  and  mitigation  strategies  are  defined. 

g.  Nuclear  and  other  threats  are  translated  into  system  environments  and  modeled. 

h.  System/threat  interaction  analysis  is  performed. 

i.  Hardness  levels  and  definition  of  hardness  margins  and  design  criteria  are  identified. 

4.3.7  Environmental,  Safety,  and  Occupational  Health  (ESOH) 

a.  System-level  ESOH  requirements  are  defined,  allocated,  baselined,  and  traced  to  the  system- 
level  requirements: 

( 1 )  Hazards  are  identified. 

(2)  Hazardous  materials  are  analyzed,  including  handling  and  disposal. 

(3)  Mitigation  decisions  are  evaluated. 

(4)  Residual  risk  acceptance  is  evaluated. 

(5)  Current  mitigation  efforts  are  assessed. 
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(6)  National  Environmental  Policy  Act  (NEPA)  and  Programmatic  Environmental,  Safety, 
and  Elealth  Evaluation  (PESE1E)  requirements  are  incorporated. 

b.  ESOE1  risks  and  corrective  actions  and  alternatives  are  developed  to  eliminate  or  reduce 
environmental,  health,  and  identified  hazards  and  unsafe  conditions;  and  the  threat  of 
regulatory  violations  is  identified. 

c.  Criteria  are  established  for  monitoring  and  reporting  of  pollution  elimination/reduction 
efforts. 

d.  A  containment  program  is  developed,  including  procedures  for  safe  use  and  disposal. 

e.  Elandling  and  disposal  of  hazardous  material  are  included  in  life  cycle  cost  estimates. 

4.3.8  Contamination 

a.  Requirements  for  contamination  control  are  identified  for  sensitive  components  or 
subsystems,  including: 

(1)  Need  for  normal,  medium,  or  challenging/stressing  contamination  control  to  meet 
requirements. 

(2)  Any  needs  for  new  or  upgraded  facilities. 

(3)  Shipping  and  prelaunch  operations. 

b.  Cleanliness  challenges  are  identified  and  solutions  proposed,  including: 

(1)  Uncleanable  materials. 

(2)  Solvent  incompatibility. 

(3)  Mission-unique  requirements  to  launch  vehicle. 

(4)  Eligh  outgassing  materials. 

c.  Heritage  analysis  comprehensively  and  completely  demonstrates  that  prelaunch  cleanliness 
requirements  can  be  met  and  that  overall  end-of-life  (EOL)  requirements  can  be  met. 

4.3.9  Mass  Properties 

a.  Mass  properties  requirements  are  reviewed  and  generated;  changes  are  proposed  where 
applicable. 

b.  Baselined  design  is  reflected  in  the  mass  properties  analyses  and  reports. 

c.  Subsystem  and  subcontractor’s  definition  of  critical  mass  properties  parameters  are  reviewed 
and  tracked  to  ensure  that  specification  requirements  are  met. 
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d.  Configuration  layout  for  optimizing  mass  properties  (weight,  balance,  and  inertia)  is 

analyzed. 

e.  Balance  weight  locations  are  defined.  Provisions  for  balance  weight  installation  are  ensured. 

f.  Test  plan  and  test  procedure  are  generated;  method  of  verifying  requirements  is  defined; 

required  mechanical  ground  support  equipment  (MGSE)  is  identified. 

.10  Logistics 

a.  Logistics  requirements  are  defined,  allocated,  baselined,  and  traced  to  system  requirements. 

Logistics  management  information  (LMI),  life  cycle  cost  (LCC)  analysis  with  a  discussion  of 

risks,  and  any  risk  reduction  or  control  are  included  for  the  following  logistics  areas: 

(1)  Design  interface  -  system  reliability,  maintainability,  availability,  survivability, 
including  hardness  and  unique  characteristics. 

(2)  Support  concepts/maintenance  plan  -  initial  and  steady-state  support;  implementation 
and  transition  schedule  at  organizational  and  depot  level;  warranties  and  SORAP. 

(3)  Manpower  and  personnel  -  operations,  maintenance  (hardware  and  software),  and 
training  support  personnel. 

(4)  Supply  support  -  support  concept  for  initial  and  steady  state,  sparing  requirement  to 
support  concept  of  operation. 

(5)  Support  equipment  and  simulators  -  common  and  specialized  organizational  and  depot 
support  equipment,  and  system-level  simulators  and  trainers. 

(6)  Training  and  training  support  -  initial  and  follow-on  training,  equipment, 
documentation  and  facilities;  student  requirements. 

(7)  Technical  data  -  engineering  drawings  and  technical  orders;  data  rights,  technical 
manual  contract/delivery  requirements. 

(8)  Computer  resource  support  -  software  and  database  maintenance,  facilities,  equipment, 
COTS,  and  documentation. 

(9)  facilities  -  Space  projections,  new  or  reuse  requirements,  site  survey,  deployment 
transportable  facilities. 

(10)  Packaging,  handling,  storage  and  transportation  (PHS&T)  -  LMI  packaging  analysis, 
government  and  commercial  packaging  requirements,  and  packing  requirement  meet 
all  concept  of  operations,  including  deployment  storage,  oversized  and  special 
packaging  instruction,  air,  ground,  or  sea  shipping  requirements. 


4.3.11  Human  Systems  Integration  (HSI) 


Note:  This  section  presents  requirements  for  the  systems  engineering  planning  activities  associated 
with  human  systems  integration.  The  requirements  for  the  subordinate  domains  are  contained  within 
specific  domain-level  standards. 

4.3.1 1.1  Scope  and  Nature  of  Work 

Human  systems  integration  (HSI)  shall  be  applied  as  part  of  the  overall  systems  engineering  effort  to 
efficiently  and  effectively  integrate  humans  into  the  design  of  the  system.  The  goals  of  the  human 
systems  integration  effort  shall  be  to: 

a.  Plan  and  execute  efficient  development  of  systems  that  effectively  integrates  human 
operators,  maintainers,  support  personnel,  and/or  users. 

b.  Plan  for  impacts  of  military  system  operation,  use,  or  disposal  on  potentially  affected  general 
populations. 

c.  Ensure  system  performance  by  ensuring  human  integration  and  specified  levels  of 
performance. 

d.  Apply  to  all  aspects  of  military  systems,  equipment,  and  facilities  acquisition,  including 
analysis,  design,  development,  acquisition,  test  and  evaluation,  sustainment,  and  product 
improvement. 

e.  Implement  by  making  effective  demands  upon,  and  tradeoffs  between,  personnel  resources, 
skills,  and  training  to  allow  for  knowledgeable  management  of  total  system  ownership  costs. 

4.3.11.2  HSI  Planning 

HSI  shall  be  part  of  the  overall  systems  engineering  effort  within  the  total  project  and  shall 
coordinate  with  all  appropriate  systems  engineering  specialties  or  disciplines.1 

a.  HSI  planning  shall  establish  the  collaboration  between  HSI  domain  disciplines  with  emphasis 
on  each  domain  area’s  participation  in  system  (hardware  and  software)  design  and  testing. 

b.  HSI  shall  be  documented  and  managed  accordingly. 

c.  Risk  management  —  HSl-related  risks  and  issues  that  involve  technical,  cost,  or  schedule 
risks  shall  be  identified  and  managed  as  early  as  possible  as  part  of  a  program’s  overall  risk 
management  approach. 

d.  Reviews  —  HSl-related  activities  shall  be  reported  in  all  appropriate  programmatic  or 
technical  reviews. 

The  contractor  shall  establish  a  comprehensive  Human  Systems  Integration  (HSI)  effort  as  part  of  the 
overall  systems  engineering  effort. 


1  Support  material  for  HSI  planning  can  be  found  in  The  Aerospace  Corporation  report  TOR-2012(8960)-1  REV  A  -  HSI 
Planning  Requirements. 
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a.  HSI  shall  address  the  following  discipline  areas2: 

(1)  Manpower  -  number  and  mix  (military,  contractor,  and  civilian)  of  personnel  required, 
authorized,  and  available  to  train,  operate,  maintain,  and  support  the  system. 

(2)  Personnel  -  human  aptitudes,  skills,  experience  levels,  and  abilities  required  to  operate, 
maintain,  and  support  the  system  when  fielded  and  throughout  its  life  cycle. 

(3)  Training  -  instruction  and  resources  required  to  provide  the  necessary  knowledge,  skills, 
and  abilities  to  properly  integrate,  operate,  maintain,  and  support  the  system. 

(4)  Human  factors  engineering  -  integration  of  human  capabilities  (cognitive,  physical, 
sensory,  and  team  dynamics)  into  system  design,  development,  modification,  and 
evaluation  to  optimize  human-machine  interactive  performance  for  operation  and 
maintenance  of  the  system. 

(5)  Environment  -  issues  related  to  water,  air,  and  land  and  the  interrelationships  between 
these  and  all  living  things. 

(6)  Safety  -  issues  including  design  of  operational  systems  to  minimize  the  possibilities  for 
accidents  or  mishaps  that  threaten  the  survival  of  the  system. 

(7)  Occupational  health  -  minimizing  risk  of  injury,  acute  and/or  chronic  illness,  disability, 
and/or  reduced  job  performance  to  personnel  who  operate,  maintain,  or  support  the 
system. 

(8)  Survivability  -  minimizing  risk  of  fratricide,  detection,  and  probability  of  being  attacked; 
and  inclusion  of  factors  that  enable  the  crew  to  withstand  man-made  or  natural  hostile 
environments  without  aborting  mission  or  suffering  acute/chronic  illness  or  death. 

(9)  Habitability  -  living  or  working  conditions  necessary  to  sustain  the  morale,  safety,  health, 
and  comfort  of  the  user/maintainer  population,  contributing  directly  to  personnel 
effectiveness  and  mission  accomplishment. 

The  HSI  activities  shall  be  integrated  into  the  overall  systems  engineering  program  and  management. 
The  HSI  requirements  specified  herein  shall  be  coordinated  with,  but  shall  not  duplicate,  efforts 
performed  to  fulfill  other  contractual  program  tasks.  The  HSl-related  portion  of  any  analysis,  design, 
or  test  and  evaluation  program  shall  be  conducted  under  the  direct  cognizance  of  a  qualified  HS1- 
domain  practitioner(s)  assigned  such  responsibility  by  the  contractor.  “Qualified”  should  consider 
basis  of  education,  experience,  and/or  certification  in  systems  engineering,  human  systems 
integration,  or  any  of  the  individual  HSI  domains. 

a.  The  contractor  shall  determine  the  scope  and  nature  of  HSI  domain  area  applicability  such 

that: 

(1)  Program/contract  requirements  are  allocated  to  the  appropriate  HSI  domain  (discipline) 
areas. 


2  Individual  DOD  services/components  may  organize  these  same  domain  areas  into  different  domain  area  combinations. 
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(2)  Responsible  entities  (e.g.,  HS1  Working  Group  and/or  Integrated  or  Cross  Product  Teams  - 
IPTs)  are  identified  for  each  applicable  HS1  domain  within  the  systems  engineering  1PT 
structure. 

(3)  Key  or  lead  HS1  personnel  in  all  applicable  domains  are  identified  and  described  in  terms 
of  qualifications. 

(4)  Interfaces  between  related  HS1  domains  are  defined  and  developed  to  ensure 
comprehensive  and  effective  execution  of  human-related  requirements. 

(5)  Interfaces  are  established  between  the  prime  contractor  and  all  subcontract  or  vendor  HS1 
activities. 

(6)  Domain  interdependencies  and  tradeoffs  are  identified  to  ensure  humans  are  considered 
as  part  of  system  design  on  par  with  the  hardware  and  software. 

b.  HS1  planning  shall  be  described  in  a  configuration-managed  document  that  is  used  to  execute 
the  HS1  effort. 

c.  HS1  planning  shall: 

(1)  Include  the  human-related  tasks  to  be  performed,  milestones,  level  of  effort,  methods,  and 
design  concepts  to  be  used,  and  the  test  and  applicable  evaluation  methodologies. 

(2)  Describe  data  flow  between  HS1  domains  and/or  IPTs  (see  Appendix  B  Giver-Receiver 
relationships). 

(3)  Be  documented  as  a  human  systems  integration  plan  and/or  within  the  Systems 
Engineering  Management  Plan  (SEMP). 

(4)  Be  validated/updated  prior  to  major  programmatic  and  technical  reviews. 

(5)  Be  updated  at  program  rebaseline  and/or  engineering  change  proposal  (ECP). 

d.  The  following  activities  shall  be  considered: 

(1)  Integration  of  relevant  human-related  data  and  analyses  into  all  design  and  development 
activities  with  human-related  requirements,  design  features,  or  implications,  especially 
considering  the  relationships  between  these  efforts  and  opportunities  to  effect  efficiencies 
in  system  development,  operation,  and  maintenance. 

(2)  HS1  implications  for  integrated  development  of  logistics  and  operational  support 
materials,  including  procedures,  manuals,  and  technical  documentation. 

(3)  User  involvement  and  community  review  of  human-related  activities  and  products, 
including  prototype  assessments,  peer  reviews,  and  formal  reviews. 

(4)  Verification  and/or  validation  of  human  requirements  and  human-related  design 
options/solutions. 
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The  contractor  shall  identify  and  manage  human-related  risks,  issues,  and  opportunities  in  a  way  that: 

a.  Ensures  HSl-related  risks  are  managed  within  the  program’s  risk  management  process. 

b.  Identifies  potential  cost,  schedule,  technical,  and  performance  risks  that  result  from  human 
system  integration. 

c.  Quantifies  such  risks  and  their  impacts  on  cost,  schedule,  and  performance. 

d.  Evaluates  and  defines  the  sensitivity  of  HSl-related  risks. 

e.  Identifies  alternative  solutions  to  HSl-related  problems  and  defines  the  associated  risks  of 
each  alternative. 

f.  Documents  the  identified  risks,  their  potential  impact,  and  the  mitigation  action(s)  taken. 

g.  Manages  the  actions  required  to  avoid,  minimize,  control,  or  accept  each  HSl-related  risk. 

Human  systems  integration  domain  activities  shall  be  addressed  in  all  applicable  programmatic  and 
technical  reviews,  including  but  not  limited  to: 

a.  Programmatic  reviews,  which  include  but  are  not  limited  to  program  management  review, 
integrated  baseline  review,  and  integrated  system  review. 

b.  System  reviews,  which  include,  but  are  not  limited  to: 

(1)  Concept  and  requirements  definition. 

(2)  Analysis  of  alternatives. 

(3)  System  requirements  review. 

(4)  Preliminary  design  review. 

(5)  Critical  design  review. 

(6)  Test  readiness  reviews. 

(7)  System  safety  reviews. 

(8)  Engineering  change  proposal  reviews. 

(9)  Post-implementation  reviews. 

c.  Subsystem  and  other  lower-level  reviews  including,  where  applicable,  software  specification, 
test  readiness,  and  functional  reviews  (e.g.,  support,  training,  systems  engineering,  test,  and 
manufacturing). 
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4.3.12  System  Security  and  Information  Assurance 


a.  A  system  security  program  is  implemented  that  includes  Information  Systems  Security 
Engineering  (1SSE). 

b.  Protection  needs  are  documented,  including  identification  of  mission  assets  and  assessment  of 
threats  to  those  assets. 

c.  System  security  requirements  are  defined  and  complete.  Includes  system-specific  threats  and 
compliance  with  applicable  DOD,  national,  and  international  system  security  policies. 

Includes  system  security  design  constraints. 

d.  System  security  architecture  and  management  plan  is  documented. 

e.  Security  design,  including  constraints  and  tradeoffs,  is  detailed;  cryptography  plans  are 
coordinated  with  the  National  Security  Agency. 

f.  Certification  and  accreditation  process  activities  are  coordinated. 

g.  Protection  mechanisms  have  been  verified  to  satisfy  security  requirements  and  residual 
security  risks  have  been  approved  by  the  appropriate  authorities. 

4.3.13  Reliability 

a.  Space  system-specific  reliability  requirements  are  defined,  allocated,  baselined,  and  traceable 
to  system  requirements. 

(1)  Parameters  and  limits  are  defined  at  this  level  and  provided  within  the  system 
specification. 

(2)  Reliability  requirements  are  reviewed  against  functional  requirements  and  customary 
design  practices. 

b.  Applicable  specific  design  tasks  and  analyses  are  conducted,  including: 

(1)  Failure  Reporting  Analysis,  Corrective  Action  System  (FRACAS). 

(2)  Source  selection  and  vendor  control  procedures. 

(3)  Failure  Modes  Effects  and  Criticality  Analysis  (FMECA). 

(4)  Derating  and  margins  of  safety. 

(5)  Fault  coverage. 

(6)  Single-point  failure. 

(7)  Redundancy/single  string. 
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c.  The  reliability  program  plan  and  risk  management  plan  are  developed  for  final  top-level 
space  system. 

d.  Items  in  development  that  have  impact  on  support  resources  are  identified,  including  time, 
people,  money,  parts,  tools,  storage,  and  transportation  assets. 

4.3.14  Electromagnetic  Interference  and  Compatibility  (EMI/EMC) 

a.  EMI/EMC  requirements  are  defined,  allocated,  baselined,  and  traced  to  system  requirements, 
including: 

(1)  Use  of  RF  shielded  enclosures  for  vehicle,  subsystems,  or  components,  and  other 
significant  design  features  affecting  EMC. 

(2)  Structure  RF  shielding  effectiveness  in  excess  of  40  dB. 

(3)  Return  of  power  on  spacecraft  structure. 

(4)  Unshielded  or  untwisted  or  unpaired  wires. 

(5)  Radiated  emissions  requirements  less  than  20  dBuV/m. 

(6)  Gimbals  that  form  part  of  a  shielded  enclosure — high  risk. 

(7)  Radiated  susceptibility  requirements  in  excess  of  100  V/m — high  risk. 

(8)  Systems  having  passive  intermodulation  products  of  order  7  or  less  in  platform  receiver 
pass  bands. 

(9)  Any  EMC  wire  shields  or  grounds  that  are  required  to  flex  or  rotate  or  rub/roll  more 
than  20  times. 

(10)  Magnetic  dipole  requirements  more  stringent  than  3.5E-3  A-mA2/kg. 

(11)  All  first-flight/first-use  EMC  parts. 

(12)  All  cryo-cooled  sensor  EMC  designs. 

(13)  All  EMC  requirements  with  negative  margin. 

(14)  Any  RF  receiver  required  to  work  in  a  dense  EMI  environment. 

(15)  Any  RF  receiver  with  a  burnout  level  of  less  than  30  dBm  (1  mW). 

b.  A  summary  of  all  significant  areas  are  addressed  in  the  EMC  Control  Plan,  including  but  not 
limited  to  program  requirements  tailoring  and  the  use  of  heritage  equipment  and  other  ND1. 

c.  EMC  requirements  verification  planning  to  the  unit  level  is  conducted. 

d.  EMFEMC  risk  areas  are  identified  and  risk  mitigation  closure  plans  developed. 


50 


4.3.15  System  Safety 


a.  System  safety  requirements  are  defined,  allocated,  baselined,  and  traced  to  system 

requirements,  including: 

(1)  System  safety  design  requirements  are  specified  and  safety  design  criteria  determined. 

(2)  Hazards  associated  with  the  system  are  identified  and  risks  involved  identified;  hazard 
analysis  is  complete. 

(3)  Risks  are  minimized  in  the  design,  materials,  testing,  and  production  of  end  item. 

(4)  Retrofit  actions  are  minimized  by  inclusion  of  safety  features  during  definition  and 
development  of  system. 

(5)  Retrofit  actions  are  minimized  by  inclusion  of  safety  features  during  definition  and 
development  of  system. 

b.  Hazardous  substances,  components,  and  operations  are  isolated  from  other  activities,  areas, 

personnel,  and  incompatible  materials. 

c.  Catastrophic  risks  are  eliminated. 

d.  Critical  hazards  are  minimized. 
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5.  Notes 


5.1  Intended  Use 

This  section  contains  information  for  reference  only. 

The  primary  purpose  of  this  document  is  to  be  specified  by  the  government  on  space  system 
development  contracts  as  a  compliance  document.  Therefore,  the  requirements  herein  are  intended  to 
be  contractor  requirements.  This  document,  however,  can  be  used  by  the  government  as  a  guide  to 
assist  in  systems  engineering  planning  in  terms  of  the  required  systems  engineering  efforts.  Programs 
for  which  a  government  activity  plays  a  “contractor”  role  should  implement  this  standard  under  a 
“contract”  to  the  tasking  government  activity.  A  single,  integrated  set  of  technical  tasks  should  be 
developed.  This  can  be  accomplished  by  integrating  all  the  tasks  in  the  contract’s  statement  of  work 
(SOW);  tailoring  this  document  to  include  tasks  from  other  standards  selected  for  contractual 
application;  executing  the  complete,  integrated  task  set  via  the  Systems  Engineering  Management 
Plan  (SEMP);  or  using  some  appropriate  combination  of  these  alternatives.  Regardless  of  the 
approach  taken  to  place  the  tasks  of  this  standard  on  contract,  the  SEMP  should  be  the  single, 
integrated  technical  planning  document. 

This  standard  can  be  used  by  the  government  as  follows: 

a.  For  defining  the  government’s  requirements  for  systems  engineering  in  a  request  for  proposal 
(REP)  or  contract.  Toward  this  end,  the  requirements  in  this  section  can  be  applied  by 
tailoring  the  requirements  in  Subsection  3.2  and  definitions  in  Appendix  C  consistent  with  the 
objectives  and  constraints  of  the  program  and  contract,  or  by  developing  tailoring  for 
additional  government,  NSS  industry,  or  professional  society  systems  engineering  standards 
to  bring  them  into  compliance  with  Sections  3.2  and  Appendix  C.  The  resulting  document(s) 
should  then  be  included  in  the  list  of  compliance  documents  in  the  RFP. 

b.  To  be  incoiporated  by  reference  in  Section  M  of  the  RFP,  “Evaluation  Criteria  and/or  Source 
Selection  Standards”  for  evaluating  either  of  the  following: 

(1)  Proposed  alternative  standards  or  corporate  policies. 

(2)  Further  tailoring  of  a  standard  listed  in  the  RFP. 

The  tailored  standard  that  proves  to  be  acceptable  to  the  government  should  then  be  placed  on 
contract  as  a  compliance  document. 

c.  As  a  “checklist”  for  monitoring  the  contractor’s  systems  engineering  processes  and  products. 

This  standard  applies  to  all  acquisition  phases  of  DOD1  5000.02.  The  requirements  herein  provide 
important  steps  in  implementing  DOD  direction  to  managed  acquisition  programs  through  the 
application  of  a  systems  engineering  approach  that  optimizes  total  system  performance  and  minimizes 
total  ownership  costs.  The  continuous  application  of  a  robust  systems  engineering  methodology  also 
serves  as  a  way  to  ensure  effective  sustainment  of  weapon  systems  through  design  and  development 
of  reliable  and  maintainable  systems. 

Many  other  DOD  directives  and  instructions,  such  as  those  for  affordability,  safety,  and  human 
factors,  also  require  “the  continuous  application  of  a  robust  systems  engineering  methodology.” 
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While  all  of  the  requirements  in  Subsection  4.2  collectively  respond  to  these  directives,  those  under 
Tradeoff  Analyses  and  Effectiveness  and  Cost  Analyses  are  specifically  responsive. 

Similarly,  systems  engineering  is  a  core  issue  to  be  addressed  at  each  major  milestone  review. 

5.2  Systems  Engineering — Concept 

Systems  engineering  (SE)  is  the  interdisciplinary  approach  for  encompassing  the  entire  set  of 
scientific,  technical,  and  managerial  efforts  needed  to  provide  a  set  of  life  cycle  balanced  system 
solutions  that  satisfy  customer  needs.  Throughout  this  standard,  “balanced”  refers  to  system 
requirements  and/or  the  corresponding  design  for  which  the  capabilities  to  be  provided,  cost, 
schedule,  risk,  and  potential  for  evolutionary  growth  have  been  assessed  and  found  to  be  acceptable  in 
the  context  of  the  program  that  is  to  satisfy  the  requirements.  The  SE  process  is  an  iterative, 
disciplined  method  that  includes  requirements  analysis,  requirements  allocation,  design  synthesis,  and 
technical  management  processes.  This  process  takes  place  over  the  entire  life  cycle,  from  needs 
definition  to  system  disposal,  and  applies  to  all  levels  of  acquisition  from  systems  of  systems  (SoS)  to 
individual  platforms,  systems,  subsystems,  and  components.  System  success  is  dependent  on  the 
extent  to  which  these  systems  satisfy  their  stakeholders’  needs,  are  affordable,  are  acquired  on  time, 
work  with  other  systems  in  a  coherent  family  of  systems,  and  can  be  changed  over  time  to  meet 
changing  requirements.  Stakeholders  consist  of: 

(1)  All  individuals  and  organizations  whose  mission  success  is  enabled  by  the  capabilities 
embodied  in  the  systems. 

(2)  All  individuals  and  organizations  responsible  for  system  operations  and  maintenance. 

Both  the  tasking  organization  and  the  performing  organizations  perform  the  systems  engineering 
process  and  activities.  Together  they  must  manage  requirements,  including  managing  change,  so  that 
stakeholders’  needs  are  always  reflected  in  the  most  recent  requirements  baseline.  The  focus  of  this 
document  is  on  the  requirements  for  the  contractor,  but  information  is  provided  to  assist  the 
government.  Systems  engineering  is  thus  a  disciplined  acquisition  approach  that  requires  identifying 
stakeholder  requirements  to  a  level  of  detail  sufficient  to  design  and  build  the  system,  to  make  trades 
between  alternative  means  of  satisfying  these  requirements,  to  select  the  tradeoff  alternatives  that 
balance  performance,  cost,  schedule,  risk,  and  potential  for  evolutionary  growth,  and  to  identify  the 
interfaces  (both  internal  to  the  system  and  external  to  it)  necessary  so  that  the  system  or  family  of 
systems  can  achieve  success.  It  is  vitally  important  that  systems  engineering  be  approached  as  the 
discipline  guiding  all  acquisition  activities  and  not  as  a  compliance  afterthought. 

Systems  engineering  defines  a  tradespace — the  set  of  possible  solutions  to  stakeholder  needs.  The 
government  should  ensure  that: 

( 1 )  A  wide-enough  tradespace  is  defined  so  that  a  reasonable  range  of  tradeoff  decisions 
can  be  made. 

(2)  The  specific  design,  which  includes  the  hardware  and  software  needed  to  achieve  a 
solution,  is  left  to  the  contractor. 

There  are  two  systems  engineering  perspectives.  Both  are  needed  to  help  ensure  successful  systems 
acquisitions. 
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The  first  is  that  of  a  series  of  discrete  steps  occurring  sequentially  over  time.  Here,  work  products  are 
successively  refined  through  various  control  gates,  such  as  technical  reviews  or  acquisition  phases. 
The  second  perspective  is  that  a  set  of  technical  activities  occurs  throughout  the  entire  life  cycle.  This 
set  includes  requirements  analysis,  verification  and  validation,  test,  and  synthesis.  Further,  these 
activities  must  address  the  system  functions  needed  for  the  system’s  development,  operation,  mainte¬ 
nance,  and,  eventually,  disposal.  The  technical  activities  set  thus  pertains  to  the  process  of  designing 
and  implementing  a  system.  The  system  functions,  which  must  be  addressed  by  the  technical  activi¬ 
ties,  pertain  to  the  product  itself. 

While  this  technical  activities  set  is  performed  over  the  life  cycle,  the  relative  importance  of  each  of 
the  activities  will  vary,  as  will  the  produced  work  products.  Early  on  in  the  life  cycle,  for  example, 
requirements  analysis  will  be  emphasized  more  heavily  than  test,  and  the  work  products  produced 
will  consist  of  high-level  operational  architectures.  On  the  other  hand,  later  in  the  life  cycle,  during 
detailed  design,  the  importance  of  test  relative  to  other  activities  will  increase.  The  output  work 
products  produced  will  likely  be  detailed  specifications  at  the  subsystem  level. 

Through  successive  iterations  of  the  systems  engineering  process,  the  system  will  be  decomposed  into 
subsystems.  Some  of  these,  in  turn,  will  be  further  decomposed  into  lower-level  subsystems.  For  each 
system  or  subsystem  so  defined,  the  technical  activities  set  will  be  performed  to: 

(1)  Translate  the  input  requirements  and  architectures  into  a  build-to  specification  (the 
allocated  baseline). 

(2)  Define  the  inputs  to  yet  another,  lower-level  set  of  subsystems. 


Systems  engineering  thus  provides  an  effective  means  to  deal  with  the  modem  system’s  complexity. 
A  complex  problem  is  transformed  into  a  succession  of  smaller  problems.  These  are,  in  turn, 
transformed  into  still  smaller  problems.  This  process  continues  until  a  hardware/software  solution  can 
be  implemented. 

Throughout  this  iterative  process,  the  outputs  of  technical  activities  must  be  integrated  and  reviewed 
at  the  control  gates  occurring  at  discrete  points  in  time.  These  reviews  are  part  of  the  contract 
management  activities  that  ensure  that  time  and  budget  are  being  well  spent,  and  that  progress  is 
sufficient  to  ensure  that  the  required  capabilities  will  be  delivered  in  a  timely  and  cost-effective 
manner.  Thus,  a  disciplined  acquisition  approach  is  achieved.  The  work  products  are  matured  over 
control  gates  as  appropriate  to  the  specific  acquisition  phases.  The  systems  engineering  technical 
activities  (requirements  analysis,  functional  analysis/allocation,  synthesis,  and  systems  analysis  and 
control)  span  all  control  gates.  And  these  technical  activities  must  address  all  functions  needed  across 
the  system’s  life  cycle. 

Tailoring  the  systems  engineering  process  is  achieved  by  deciding  (1)  which  control  gates  to  use  and 
(2)  how  far  to  decompose  the  system  and,  thus,  how  much  iteration  of  technical  activities  is  needed 
for  successful  system  acquisition.  For  example,  a  relatively  simple  system  (e.g.,  a  single  black  box  to 
be  installed  on  a  weapon  system)  will  likely  require  fewer  decomposition  levels  and  technical  activity 
iterations  than  would  the  whole  weapon  system.  Likewise,  a  purely  software  system  would  likely 
have  different  control  gates  than  would  a  hardware  and  software  system. 

Systems  engineering  supports  the  DOD  acquisition  process,  implementing: 
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(1)  A  shift  from  a  requirements  basis  to  a  capabilities  basis  for  designing  a  system. 

(2)  Insistence  that  systems  function  together  as  well  as  separately. 

(3)  Explicit  recognition  that  systems  must  be  changed  over  time  to  meet  changing  needs. 

5.3  Data  Requirements 

In  the  development  of  national  security  space  systems,  it  is  the  responsibility  of  the  government  to 
ensure  that  adequate  systems  engineering  processes  are  implemented.  Systems  engineering  data 
requirements  for  contractor(s)  need  to  be  established  during  preparation  of  the  request  for  proposal 
and  the  contract.  Contract  Data  Requirements  List  (CDRL)  items  enable  the  government  to  specify  to 
the  contractor(s)  what  SE  data  is  required  and  when  needed.  These  Data  Item  Descriptions  (DIDs) 
must  be  listed,  as  applicable,  on  the  Contract  Data  Requirements  List  (DD  Form  1423)  when  this 
standard  is  applied  on  a  contract  in  order  to  obtain  the  data,  except  where  DOD  FAR  Supplement 
227.405-70,  Data  Requirements  exempts  the  requirement  for  a  DD  Form  1423. 

SE  CDRL  Item  Reference: 


1. 

2. 

3. 

4. 

5. 

6. 

7. 

8. 

9. 

10. 
11. 
12. 

13. 

14. 


Systems  Engineering  Management  Plan  (SEMP) 

Risk  Management  Plan . 

Configuration  Management  Plan . 

System  Verification  Deliverables . 

System/Segment  Interface  Control  Specification. 
Logistics  Management  Information . 

System/Subsystem  Specification . 

Contract  Work  Breakdown  Structure  (CWBS) .... 

Integrated  Master  Schedule  (IMS) . 

Design  Review  Information  Package . 

Engineering  Change  Proposal  (ECP) . 

Failure  Summary  and  Analysis . 

Data  Accession  List  (DAL) . 

Fluman  Systems  Integration  Plan . 


Dl-SESS-81785 

ISO  17666:2003 

D1-CMAN-80858B 

A1AA-S-1 17-2010,  Annex  B  and  D 

D1-SESS-81314A 

Dl-ALSS-81529 

Dl-ALSS-81530 

D1-1PSC-81431A 

D1-MGMT-81334C 

Dl-MGMT -81650 

D1-SESS-81757A 

D1-CMAN-80639C 

D1-REL1-80255 

Dl-MGMT -8 1 453 A 

Appendix  D  of  this  document 


Many  of  the  Data  Item  Descriptions  (DIDs)  to  be  used  in  CDRL  preparation  are  maintained  in  an 
online  database,  the  Acquisition  Management  Systems  and  Data  Requirements  Control  List 
(AMSDL)  within  the  Acquisition  Streamlining  and  Standardization  Information  System  (ASSIST), 
maintained  by  the  Defense  Logistics  Agency.  The  AMSDL  contains  source  documents  and  data  item 
descriptions  that  have  been  approved  for  repetitive  contractual  application  in  DOD  acquisitions. 


5.3.1  Tailoring  Guidance 


This  standard  should  be  tailored  to  the  specific  requirements  of  a  particular  program,  program  phase, 
or  contractual  structure  as  directed  by  the  government.  Tasks  that  add  unnecessary  costs,  data,  and 
any  factors  that  do  not  add  value  to  the  process  or  product  should  be  eliminated.  Tailoring  takes  the 
form  of  deletion  (removal  of  tasks  not  applicable),  alteration  (modifying  tasks  to  more  explicitly 
reflect  the  application  to  a  particular  effort),  or  addition  (adding  tasks  to  satisfy  program 
requirements).  Tailored  requirements  and  task  statements  may  be  used  in  preparing  solicitation 
documents  as  well  as  by  offerors  in  response  to  a  request  for  proposal. 
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5.3.2  Tailoring  Considerations 

The  systems  engineering  process  and  products  discussed  in  this  standard  are  applicable  to  all  aspects 
of  system  development,  irrespective  of  complexity,  risk,  or  scope.  However,  the  system  functions  to 
which  these  processes  will  be  applied  (as  well  as  the  number  and  sequencing  of  technical  reviews,  the 
use  of  iteration  and  recursion,  and  the  specific  systems  engineering  model  and  artifacts  produced)  will 
vary,  depending  on  the  specific  system  being  developed  and  contractual  requirements.  In  addition,  the 
relative  intensity  of  the  various  systems  engineering  activities  within  the  systems  engineering  process 
can  also  vary  from  one  system  acquisition  to  the  next.  Tailoring  of  this  guidance  informs  the 
government  of  the  contractor’s  choice  of  tools,  measurements,  metrics,  and  specific  systems 
engineering  methods  and  tasks.  The  contractor’s  tailoring  of  this  guidance  is  subject  to  the 
government’s  direction  and  approval. 

The  objectives  of  the  contract  define  the  breadth  and  depth  of  the  systems  engineering  process  for  that 
specific  procurement.  To  assist  in  tailoring  the  application  of  SE  requirements  in  this  document  and 
the  associated  level  of  effort  for  systems  engineering  tasks  in  a  particular  procurement,  the  following 
inputs  should  be  considered. 

5. 3. 2.1  Applicable  Acquisition  Guidance 

Systems  may  be  acquired  under  different  acquisition  guidance,  such  as  DOD  or  NRO  regulations, 
depending  upon  who  the  acquiring  organization  is.  These  may  have  a  different  emphasis  regarding 
upfront  versus  follow-on  effort,  and  the  degree  of  system  definition  required  at  the  various  acquisition 
milestones  and  reviews. 

5. 3. 2. 2  Acquisition  Strategies 

Evolutionary  acquisition  is  described  in  the  DOD  5000  series  and  is  the  preferred  strategy  for  rapid 
acquisition  of  mature  technology.  Evolutionary  acquisition  delivers  capability  in  increments  or 
spirals,  which  have  quite  different  implications  for  systems  engineering. 

Competitive  prototyping  is  described  in  the  Weapons  Systems  Acquisition  Reform  Act  (WSARA)  of 
2009  as  a  preferred  strategy  for  Phase  A  (and  earlier)  acquisitions. 

5. 3. 2. 3  New  Development  vs.  COTS  Systems  [3] 

COTS-intensive  systems  will  generally  require  greater  attention  to  selection  of  the  COTS  compo¬ 
nents,  engineering  the  integration  and  assembly  sequence,  to  integration  and  assembly  of  the  COTS 
components,  and  to  technology  refresh. 

5. 3. 2. 4  Software  vs.  Hardware  and  Software  Systems 

Systems  that  are  predominantly  software  in  nature  will  typically  use  different  control  gates  than  will 
systems  that  consist  of  both  hardware  and  software. 

5. 3. 2. 5  System  Size  and  Complexity 

In  general,  systems  that  are  very  large  and  complex  will  require  more  control  gates  and  milestones, 
and  more  elaborate  entry  and  exit  criteria. 
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5.3. 2. 6  System  Scope 


Prototype  systems,  systems  not  intended  for  production  and  operational  deployment,  and  systems  not 
requiring  any  disposal  (for  example,  software  systems)  will  employ  different  control  gates  and 
processes. 

5.3. 2. 7  Magnitude  of  Technical  Risk 

Systems  that  have  significant  technical  risk  will  generally  require  more  systems  analysis  and  control 
early  in  the  life  cycle  than  will  low-risk  systems. 

5.3. 2. 8  Policies,  Regulations,  Standards,  and  Laws 

Policies,  regulations,  standards,  and  laws  will  influence  the  system  functions  to  which  the  systems 
engineering  process  will  be  applied. 

5.4  Robustness  and  Flexibility 

Many  systems  produced  by  the  DOD  and  intelligence  communications  (1C)  are  very  expensive  and 
take  many  years  to  develop  and  field.  It  is  desired  that  these  systems  remain  useful,  even  if  the 
mission  for  which  they  were  originally  intended  changes  or  if  they  must  be  adapted  for  a  different 
mission.  The  terms  “robustness”  and  “flexibility”  are  often  defined  relative  to  requirements  and 
mission.  A  system  is  robust  if  it  remains  useful  even  as  the  external  environment,  which  governs  its 
mission  as  well  as  the  threats  it  must  face,  changes.  However,  the  functional  requirements  may  be 
sufficiently  broad  so  that  these  environment  changes  do  not  materially  impact  them.  A  flexible 
system,  on  the  other  hand,  will  remain  useful  even  if  its  functional  requirements  as  well  as  the 
external  environment  change  in  some  significant  way.  Flexible  and  robust  systems  are  contrasted  with 
optimized  systems,  which  cannot  readily  be  adapted  to  major  changes  in  the  environment  or  in 
functional  requirements  [4],  These  concepts  are  represented  in  Figure  5-1.  The  B-58,  in  the  lower  left 
quadrant,  was  optimized  for  a  single  mission,  that  of  delivering  nuclear  weapons  at  supersonic  speeds 
and  at  high  altitude.  Because  it  was  only  marginally  useful  for  any  other  role,  it  became  obsolete 
when  Soviet  air  defenses  improved  with  the  addition  of  long-range,  high-altitude  surface-to-air 
missiles.  The  B-52,  on  the  other  hand,  shown  in  the  upper  right-hand  quadrant  of  Figure  5-1,  has 
proven  adaptable  to  both  a  changing  external  environment  and  to  changes  in  its  functional 
requirements.  Starting  life  as  a  high-altitude  nuclear  bomber,  it  has  been  adapted  to  the  low-altitude 
nuclear,  tactical  (conventional),  and  cruise  missile  carrier  roles.  Systems  for  which  the  functional 
requirements  change  even  as  the  environment  remains  stable  are  poorly  designed;  i.e.,  the 
requirements  did  not  accurately  capture  the  capabilities  needed  in  the  first  place. 

It  should  be  noted  that  inexpensive,  short-lived,  optimized  systems  might  be  completely  appropriate 
for  some  mission  applications.  In  situations  of  great  volatility  where  required  operational  capabilities 
and  technical  requirements  are  likely  to  undergo  extreme  change,  an  inexpensive,  “throwaway”  sys¬ 
tem  may  be  preferable  to  developing  and  fielding  a  much  more  sophisticated  system  that  also  takes 
longer  to  develop  and  that  is  much  more  costly. 
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Figure  5-1.  Flexible,  robust,  and  optimized  systems. 

5.5  Evolutionary  Acquisition 

Evolutionary  acquisition  (EA)  is  described  in  the  Defense  Acquisition  Guidebook  (DAG)  as  the 
preferred  DOD  strategy  for  rapid  acquisition  of  mature  technology  for  the  user.  An  evolutionary 
approach  delivers  capability  in  increments,  recognizing,  up  front,  the  need  for  future  capability 
improvements.  The  objective  is  to  balance  needs  and  available  capability  with  resources,  and  to  put 
capability  into  the  hands  of  the  user  quickly.  The  success  of  the  strategy  depends  on  consistent  and 
continuous  definition  of  requirements  as  well  as  the  maturation  of  technologies  that  lead  to 
disciplined  development  and  production  of  systems  that  provide  increasing  capability  toward  a 
materiel  concept  [5]. 

EA  proceeds  in  increments  and  spirals.  In  a  spiral,  the  system  end  state  and  the  detailed  functional 
requirements  driving  that  end  state  are  unknown  at  the  time  the  spiral  is  started.  Functional  require¬ 
ments  are  defined  through  interaction  with  stakeholders  as  well  as  through  experimentation  and 
wargaming.  In  an  increment,  by  contrast,  the  end-state  functional  requirements  are  known.  Elowever, 
for  various  reasons,  the  government  may  defer  achieving  some  functional  requirements  until  later 
increments.  The  reason  often  cited  for  such  deferments  is  that  the  technology  required  to  achieve  the 
functional  requirements  is  too  immature,  and  that  risk  reduction  programs  must  be  implemented 
before  this  technology  can  be  safely  or  cost  effectively  integrated  with  the  system.  EA  programs 
typically  consist  of  both  increments  and  spirals. 

A  systems  engineering  program  that  effectively  supports  EA  has  several  characteristics: 

•  Detailed  requirements  and  specifications  are  developed  for  the  current  spiral  or  increment. 
Implementation  that  is  to  occur  after  this  spiral  has  many  fewer  detailed  requirements.  In  the 
case  of  a  spiral  effort,  only  the  most  general  requirements  may  be  known  for  future  spirals. 

•  Plan  for  growth  with  available  bandwidth,  electrical  power,  EIVAC,  etc.,  to  ensure  that  future 
functional  requirements  can  be  accommodated. 
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•  The  Test  and  Evaluation  Master  Plan  (TEMP)  is  tailored  for  the  current  spiral. 

•  The  Life  Cycle  Management  Plan  (LCMP)  accounts  for  multiple  versions  of  the  same  system 
since  systems  fielded  in  different  spirals  or  increments  will  be  somewhat  different. 
Alternatively,  a  decision  may  be  made  to  modify  all  systems  so  that  they  comply  with  some 
standard. 
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Appendix  A:  Foundation  for  the  Systems  Engineering  Process 

The  government  (SPO)  should  develop  or  assemble  and  maintain  the  following  types  of  data  over  the 
program  life  cycle  to  serve  as  the  foundation  for  the  systems  engineering  process.  Unless  otherwise 
prohibited  by  security  or  policy,  the  government  should  formally  transmit  the  data  to  the  system 
contractor(s)  and  tailor  the  requirements  to  define  the  use  the  contractor  is  to  make  of  each. 

Two  lists  follow.  The  first  list  applies  to  developing  and  maintaining  the  foundation  for  all  contractual 
activities  for  both  pre-acquisition  contract  phases,  including  support  to  the  definition  of  capability 
gaps  that  must  be  filled  by  materiel  programs,  analysis  of  materiel  approaches,  analysis  of  alterna¬ 
tives,  system  concept  selection,  or  development  of  a  statement  of  capability  needs  by  the  operators 
and  users  as  well  as  for  all  subsequent  acquisition  contract  phases.  The  second  list  applies  to  the 
additional  foundation  that  usually  applies  to  acquisition  contract  phases. 

a.  The  systems  engineering  foundation  to  be  developed  and  maintained  for  all  contract  phases: 

(1)  Any  and  all  results  produced  by  the  capability  needs  process,  to  include: 

(a)  Any  functional  (or  mission)  area  analyses,  plans,  concepts,  road  maps,  or  other 
related  planning  documents. 

(b)  Joint  Capabilities  Integration  and  Development  System  (JC1DS)  documents 
including  but  not  limited  to  Capability  Production  Documents  (CPD)  and 
Capability  Description  Documents  (CDD)  or  updates  of  Operational  Requirement 
Documents  (ORD). 

(c)  Any  applicable  Operational  Views  (OVs)  or  System  Views  (SVs)  as  defined  in  the 
DOD  Architecture  Framework. 

(d)  The  Concept  of  Operations  or  Operational  Employment  Concepts. 

(2)  System  Technical  Requirements  Document  (TRD) — the  document  that  identifies  the 
acceptable  system  solution  trade  space.  It  may  include  functional  and  performance 
requirements  that  are  identified  as  “to  be  determined,”  “to  be  reviewed,”  “to  be 
resolved,”  or  “to  be  supplied”  as  well  as  a  verification  strategy.  The  data  in  the 
document  is  used  by  the  performing  activity  to  initiate  Requirements  Analysis.  As  the 
program  evolves,  the  system  technical  requirements  are  refmed/resolved,  incorporated 
into  the  requirements  baseline,  and  captured  in  the  system  specification. 

(3)  Applicable  Acquisition  Decision  Memorandum  (Memoranda) — documents  system 
requirements,  objectives,  goals,  or  tradeoffs,  specifically  including  guidance  on  life 
cycle  cost  or  affordability,  technology  readiness  levels,  schedule,  or  sustainment 
objectives. 

(4)  System  threat  assessment  or  current  descriptions  for  relevant  threats  by  the  D1A  or  a 
service  intelligence  agency.  (Note:  The  potential  threats  can  depend  on  the  technical 
characteristics  of  the  solution(s),  so  the  threat  assessment  should  be  reviewed  and 
updated  as  the  solution(s)  evolve). 
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(5)  Interface/interoperability  requirements  or  constraints  imposed  by  other  systems  with 
which  the  solution  must  operate  or  share  a  boundary  (such  as  the  interface  between 
launch  and  satellite  system,  physical  and  functional  characteristics  of  electrical,  RF, 
and  software  links  to  other  systems,  including  that  for  telemetry  and  control,  interfaces 
with  systems  or  components  supplied  by  associate  contractors,  interfaces  with 
facilities,  or  interfaces  with  other  systems  in  a  family  or  system  of  systems — the  latter 
may  be  covered  to  a  degree  in  the  SVs  listed  above.) 

(6)  Applicability  of  standards  in  the  DOD  Information  Technology  Standards  Registry 
required  for  compliance  to  the  net-ready  key  performance  parameter. 

(7)  Characteristics  of  the  operating  space  and  terrestrial  environments.  These  usually 
depend  on  the  characteristics  of  the  solution(s)  such  as  the  orbit  chosen  for  the  space 
elements. 

(8)  Constraints  on  life  cycle  resource  requirements  to  include  total  budget,  budget  phasing, 
and  personnel  manpower  or  skill  levels. 

(9)  Schedule  needs  or  constraints,  including  those  imposed  by  the  military  need,  planned 
deliveries  under  other  contracts,  or  anticipated  technology  maturation. 

(10)  For  both  context  and  completeness,  the  latest  Joint  Vision,  DOD  Strategic  Plan  or  DOD 
Quadrennial  Defense  Review  (QDR),  applicable  Joint  Operations  Concepts,  and 
analysis  of  doctrine,  organization,  training,  materiel,  leadership,  personnel,  and 
facilities  (DOTMLPF)  and  other  related  joint,  DOD,  and  service  (component)  planning 
documents  and  any  relevant  portions  in  the  SE  foundation  and  the  information 
transmitted  to  the  contractor(s). 

b.  The  systems  engineering  foundation  to  be  developed  and  maintained  to  the  extent  practical 

for  any  contract  phase  that  includes  drafting,  approving,  or  maintaining  baselines, 

specifications,  or  their  equivalent  below  the  system  level  and  such  steps  as  preliminary 

design,  detailed  design,  or  design  verification: 

(1)  Capability  Development  Document  (CDD),  Capability  Production  Document  (CPD),  or 
Operational  Requirements  Document  (ORD)  updates. 

(2)  Analysis  of  Alternatives  (AoA). 

(3)  Constraints  imposed  by  law  and  regulation  to  include  acquisition,  environmental,  safety 
and  hazards  control,  human  factors,  radio  frequency  utilization,  etc.,  including  current 
versions  of  DOD,  NSS,  and  the  Air  Force  (or  other  agency)  policy  directives  and 
associated  instructions  in  each  of  these  areas. 

(4)  System  Technical  Requirements  Document.  As  the  program  evolves,  this  becomes  the 
Draft  System  Specification  and  then  the  approved  System  Specification,  including  all 
approved  changes  thereto. 
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(5)  Other  specifications  and  standards  in  the  SMC  technical  baseline3  as  well  as  handbooks 
and  manuals  related  to  systems  engineering  to  include  program  management;  work 
breakdown  structures;  configuration  management;  interchangeability,  flexibility  and 
expansion,  and  standardization;  specification  practices;  technical  reviews;  risk  analysis 
and  management;  software  requirements  analysis  and  development;  security  (physical 
security  protection,  entry/access  control),  personnel  reliability  (screening/security  pro¬ 
gram),  communications  security  (COMSEC),  computer  security,  emanations  security 
(TEMPEST),  operations  security,  and  information  security  (1NFOSEC);  Computer 
Resources  (Memory  and/or  Processing  Capacity  Reserve,  Portability  of  Software);  test 
to  include  testability  and  design  and  test  margins  for  environmental  and  operating 
conditions;  climatic  conditions;  launch  site  and  launch  range;  logistics  or  sustainment; 
nameplates  and  product  markings;  training;  modeling  and  simulation;  maintainability 
and  diagnostics;  product  assurance;  parts,  materials,  and  related  processes;  safety; 
reliability,  survivability;  mass  properties;  human  factors  and  human  engineering; 
quality;  workmanship,  producibility,  transition  to  production,  and  manufacturing; 
drawing  practices  (especially  for  hardware  planned  for  second  source  procurement); 
EMEEMC,  including  electrical  referencing  and  ground,  electrical  bonding,  and 
electrical  shielding;  corrosion  prevention  and  control;  electrostatic  discharge  control; 
welding,  soldering,  and  printed  circuit/wiring  boards;  and  subsystems  (including 
moving  mechanical;  pressure  vessels;  electrical  power  development,  including  solar 
arrays,  storage,  and  distribution;  electro-explosive  and  ordnance;  metals  including 
dissimilar  metals;  composites;  and  structures,  including  load  fators  and  factors  of 
safety). 

(6)  For  ballistic  missiles  and  other  systems  that  involve  nuclear  weapons  or  radiation 
sources  such  as  power  sources,  the  additional  program  requirements,  including  inde¬ 
pendent  reviews  for  nuclear  safety  and  surety,  or  radiation  safety,  should  be  identified. 

(7)  The  level  to  which  vulnerabilities  to  each  threat  are  to  be  controlled,  or  the  basis  (such 
as  tradeoff  ground  rules)  by  which  such  levels  are  to  be  determined/recommended  by 
the  contractor(s). 

(8)  Support  or  sustainment  concept/approach,  or  the  basis  by  which  the  contractor  is  to 
develop  the  concept — identify  key  stakeholders,  including  the 
operator/users/maintainers. 

(9)  Training  concept/approach,  or  the  basis  by  which  the  contractor(s)  is/are  to  develop  the 
concept — identify  key  stakeholders,  including  the  operator/users/maintainers,  Air 
Education  and  Training  Command  (or  other  service/agency  training,  education, 
doctrine  organizations),  and  any  others  responsible  for  training. 

(10)  The  definition  of  certification  criteria  for  Operational  Safety,  Suitability,  and  Effective¬ 
ness  (OSS&E)  and  Space  Flight  Worthiness  Certification  and  required  contractor 
support  to  and/or  certifications  of  readiness  at  independent,  mission,  flight,  and/or 
launch  readiness  reviews.  (See  SMC  Supplement  to  AF1  63-1201  and  SMC  Guides  120 
through  1204.) 


3  Contact  SMC/E  A  for  the  current  SMC  technical  baseline. 
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(11)  Philosophy,  approach,  and  requirements  for  Test-Like -You-fly  (TLYF)  and  Initial  or 
Follow-on  Operational  Testing  (10T&E  and  FOT&E) — identify  key  stakeholders, 
including  the  Operator/Users  and  the  organization  responsible  for  operational  testing 
and  evaluation  (OT&E). 

(12)  List  of  government-furnished  equipment  (GFE),  property  (GFP),  materiel  (GFM),  and 
facilities. 
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Appendix  B:  Acronyms 


This  section  provides  a  list  of  acronyms  and  abbreviations  used  in  this  standard,  with  associated 
meaning.  This  section  is  not  a  mandatory  part  of  this  standard.  The  information  contained  herein  is 
intended  for  guidance  only.  (Note:  many  terms  used  below  are  defined  in  Section  3.2.) 


AFMC 

Air  Force  Materiel  Command 

ANSI 

American  National  Standards  Institute 

APB 

acquisition  program  baseline 

ASR 

alternative  systems  review 

C/SCS 

cost/schedule  control  system 

C/SSR 

cost/schedule  summary  report 

C41 

command,  control,  communications,  computers,  and  intelligence 

C41SR 

command,  control,  communications,  computers,  intelligence,  surveillance,  and 
reconnaissance 

CA1V 

cost  as  an  independent  variable 

CARD 

cost  analysis  requirements  description 

CCPD 

combat  capability  production  document  (also  written  C-CPD) 

CDD 

capability  development  document 

CDR 

critical  design  review 

CDRL 

contract  data  requirements  list 

CFE 

contractor-furnished  equipment 

CFR 

critical  fault  risk 

Cl 

configuration  item 

CJCS 

Chairman  of  the  Joint  Chiefs  of  Staff 

CLIN 

contract  line  item  number 

CONOPS 

concept  of  operations 

COTS 

commercial  off  the  shelf 

CPD 

capability  production  document 

CPI 

critical  program  information 

CRD 

capstone  requirements  document 

CSC1 

computer  software  configuration  item 

CSOW 

contract  statement  of  work 

csu 

computer  software  unit 

CWBS 

contract  work  breakdown  structure 

DIA 

Defense  Intelligence  Agency 

DID 

data  item  description 

DOD 

Department  of  Defense 

DODAF 

DOD  architecture  framework 

DOTMLPF 

doctrine,  organization,  training,  materiel,  leadership  and  education,  personnel  and 
facilities 

EA 

evolutionary  acquisition 

ECP 

engineering  change  proposal 

EDMs 

engineering  development  models 

E1A 

Electronic  Industries  Alliance 

ESOH 

Environmental  Safety  and  Occupational  Flealth 

EVMS 

earned  value  management  system 

FCA 

functional  configuration  audit 

FMECA 

failure  mode  effects  and  criticality  analysis 
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FoS 

family  of  systems 

FOT&E 

follow-on  operational  test  and  evaluation 

FQR 

formal  qualification  review 

FRACAS 

Failure  Reporting  Analysis,  and  Corrective  Action  System 

FRD 

functional  requirements  document 

FRP 

full  rate  production 

GFE 

government-furnished  equipment 

GFI 

government-furnished  information 

GFM 

government-furnished  materiel 

GFP 

government-furnished  property 

HSI 

human  systems  integration 

HWCI 

hardware  configuration  item 

HWU 

hardware  unit 

ICA 

independent  cost  assessment 

ICD 

initial  capability  document;  interface  control  document  (or  drawing) 

ICE 

independent  cost  estimate 

ILSP 

integrated  logistics  support  plan 

IMP 

integrated  master  plan 

IMS 

integrated  master  schedule 

IAW 

in  accordance  with 

IOC 

initial  operational  capability 

IOT&E 

initial  operational  test  and  evaluation 

IPA 

integrated  program  assessment 

IPAT 

integrated  program  assessment  team 

IPD 

integrated  product  development 

IPPD 

integrated  product  and  process  development 

IPT 

integrated  product  team 

IRS 

interface  requirements  specification 

I&T 

integration  and  test 

JCIDS 

Joint  Capabilities  Integration  and  Development  System 

JTA 

joint  technical  architecture 

KDP 

key  decision  point 

KPP 

key  performance  parameter 

LCC 

life  cycle  cost 

LMU 

logistics  management  information 

LOE 

level  of  effort 

LYF 

Like  You  Fly 

MCFA 

mission  critical  fault  analysis 

MIL-HDBK 

Military  Handbook 

MIL-SPEC 

Military  Specification 

MIL-STD 

Military  Standard 

MMD 

mean  mission  duration 

MNS 

mission  need  statement 

MOE 

measure  of  effectiveness 

MOP 

measure  of  performance 

NDI 

nondevelopmental  item 

NEPA 

National  Environmental  Policy  Act 

NSS 

National  Security  System;  national  security  space 

o&s 

operations  and  support 
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OA 

ORD 

OSA 

OSS&E 

OT&E 

OV 

PCA 

PDR 

PESHE 

PHS&T 

PWBS 

REP 

SE 

SEMP 

SEP 

SFR 

SFW 

SMC 

SoS 

SOW 

SPO 

SQIC 

SRR 

STAR 

STE 

SV 

SVR 

T&E 

TA 

TBD 

TBR 

TBS 

TEMP 

TLYF 

TOR 

TPM 

TRD 

TRL 

TRR 

TV 

UPC 

WBS 


operational  architecture 

operational  requirements  document 

open  system  architecture 

operational  safety,  suitability,  and  effectiveness 

operational  test  and  evaluation 

operational  view 

physical  configuration  audit 

preliminary  design  review 

programmatic  environmental,  safety,  and  occupational  health  evaluation 

packaging,  handling,  storage,  and  transportation 

program  or  project  work  breakdown  structure 

request  for  proposal 

systems  engineering 

systems  engineering  management  plan 

systems  engineering  plan 

system  functional  review 

space  flight  worthiness 

Space  and  Missile  Systems  Center 

system  of  systems 

statement  of  work 

system  program  office 

Space  Quality  Improvement  Council 

system  requirements  review 

system  threat  assessment  report 

special  test  equipment 

systems  view 

system  verification  review 

test  and  evaluation 

technical  architecture  (as  in  TA  View) 
to  be  determined 
to  be  resolved 
to  be  supplied 

test  and  evaluation  master  plan 
Test  Like  You  Fly 
technical  operating  report 
technical  performance  measure 
technical  requirements  document 
Technology  Readiness  Level 
test  readiness  review 

technical  view,  technical  standards  view,  or  technical  architecture  view 
unit  production  cost 
work  breakdown  structure 
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Appendix  C:  Definitions 


Acceptance  -  Verification  that  a  component  or  configuration  item  meets  requirements  and 
workmanship  standards  and  is  suitable  for  use  in  its  intended  function. 

Allocated  baseline  -  Includes  (1)  the  physical  hierarchy,  (2)  the  initially  documented,  validated,  and 
approved  design-to  functional  and  performance  requirements  and  design  constraints  for  each 
system  product  in  the  hierarchy  and  all  changes  thereto  approved  in  accordance  with  the 
contract,  and  (3)  separable  documentation  identifying  all  design-to  requirements  and 
constraints  for  each  component  or  computer  software  item  and  each  separately  integrated 
grouping  of  components  and/or  computer  software  items. 

Allocation  -  (1)  All  or  a  subset  of  requirements  for  a  higher-level  system  element  that  has  been 

designated  to  be  satisfied  by  a  lower-tier  element;  (2)  the  act  of  decomposing  the  requirements 
for  a  system  among  the  elements  of  the  system. 

Alternative  systems  review  (ASR)  -  A  formal  technical  review,  usually  conducted  early  in  the 
acquisition  life  cycle  of  a  system  or  evolutionary  increment  or  spiral,  of  (1)  support  to  the 
capability  needs  process,  (2)  an  assessment  of  selected  system  concept(s)  relative  to  system 
effectiveness  in  the  intended  environment,  potential  for  growth,  affordability,  timeliness,  and 
risk,  and  (3)  the  risks  for  the  preferred  system  concept(s)  that  should  be  addressed  during 
subsequent  phases. 

Analysis  of  alternatives  (AoA)  -  The  evaluation  of  the  operational  effectiveness,  operational 

suitability,  and  estimated  costs  and  risks  of  alternative  system  concepts  to  meet  a  mission 
capability.  The  analysis  assesses  the  advantages  and  disadvantages  of  alternatives  being 
considered  to  satisfy  capabilities,  including  the  sensitivity  of  each  alternative  to  possible 
changes  in  key  assumptions  or  variables. 

Attribute  -  (1)  A  quality,  property,  or  characteristic  of  a  systems  engineering  product;  (2)  a  testable 
or  measurable  characteristic  that  describes  a  characteristic  of  a  system  or  capability. 

Balance  -  The  act  of  assessing  and  comparing  capabilities  to  be  provided,  cost,  schedule,  risk,  and 
evolvability  for  alternative  requirements,  requirements  allocations,  functional  architectures, 
and/or  designs  to  include  identifying  the  capabilities  or  constraints  that  drive  or  otherwise 
cause  high  sensitivity  to  cost,  schedule,  or  risk. 

Baseline  -  Document(s)  or  decision  database(s)  that  record  the  current  set  of  requirements  for  the 
system  and  its  design  or  system  product  solutions. 

Capability  -  The  ability  to  execute  a  specified  course  of  action.  It  is  defined  by  an  operational  user 
and  expressed  in  broad  operational  terms  in  the  format  of  an  initial  capabilities  document  or  a 
recommendation  to  change  doctrine,  organization,  training,  materiel,  leadership,  education, 
personnel,  and  facilities. 

Change  control  -  The  engineering  management  function  of  ( 1 )  limiting  change  to  a  baseline  or  other 
product  to  that  which  has  been  (a)  assessed  for  impacts  to  capabilities,  cost,  schedule,  risk, 
and  growth  potential  and  (b)  approved  by  documented  procedures  in  accordance  with  the 
contract,  and  (2)  assuring  implementation  of  all  changes  so  assessed  and  approved  to  the 
products  of  the  program. 
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Commercial  off  the  shelf  (COTS)  -  A  system  product  that  is  available  in  the  commercial 

marketplace  that  does  not  require  unique  government  modifications  or  maintenance  over  its 
life  cycle  to  meet  the  requirements. 

Component  -  A  system  product  that  is  an  aggregation  of  hardware  and/or  software  items  that  is 
viewed  as  a  separate  entity  for  purposes  of  design  or  some  other  reason,  and  for  which  the 
design  is  separately  verified.  Hardware  items  may  be  further  divided  into  additional 
components,  other  lower-tier  products  (sometimes  given  names  such  as  subassemblies),  parts, 
materials,  processes,  and  data;  software  items  may  be  further  divided  into  software  units. 

Concept  of  Operations  (CONOPS)  -  A  high-level  concept  whose  purpose  is  to  describe  a  problem 
that  combatant  commanders  may  face,  objectives  to  solve  the  problem,  desired  effects, 
capabilities  needed  to  achieve  effects,  and  sequenced  actions  that  describe  the  employment 
concept. 

Configuration  item  (Cl)  -  The  aggregation  of  system  elements  that  satisfies  an  end  use  function  and 
is  designated  for  separate  configuration  management. 

Contract  Work  Breakdown  Structure  (CWBS)  -  Work  breakdown  structure  (WBS)  prepared  by 
the  developer  to  capture  all  work  planned  under  the  contract  or  subcontract  and  that  is 
accepted  by  the  customer. 

Cost  analysis  requirements  description  (CARD)  -  The  description  of  the  salient  programmatic  and 
technical  features  of  the  program  and  the  system  it  is  to  provide  that  is  used  by  the  teams 
preparing  cost  or  schedule  analyses  or  cost  estimates. 

Cost  as  an  independent  variable  (CAIV)  -  An  approach  to  the  acquisition  of  military  systems  in 
which  cost  can  be  treated  as  a  military  requirement  and  cost,  schedule,  and  performance  may 
be  traded  within  the  tradespace  between  the  objective  and  the  threshold. 

Critical  design  review  (CDR)  -  During  system  development,  the  review  by  the  contractor  and  the 
government  of  (1)  the  status  of  any  changes  to  the  functional  baseline  and  architecture  and 
allocated  baseline  since  they  were  established,  (2)  the  design  baseline  for  each  configuration 
item,  including  the  completeness  and  compatibility  of  interfaces  between  the  items  as  well  as 
between  the  items  and  other  systems,  facilities,  and  personnel,  (3)  the  basis  for  each  element 
in  the  design  baseline  in  terms  requirements  and  objective,  comprehensive,  quantitative 
design  trades,  (4)  the  balance  between  performance,  cost,  schedule,  and  risk  for  each  element 
in  the  selected  design  baseline,  (5)  the  two-way  traceability  from  the  source  of  the  functional 
baseline  to  the  design  baseline  and  back,  and  (6)  the  verification  that  the  design  baseline  can 
meet  the  contract  requirements. 

Critical  fault  risk  (CFR)  -  A  risk  associated  with  an  unexonerated  potential  fault  or  flaw  that  would 
lead  to  mission  failure. 

Demonstration  -  The  verification  method  of  determining  performance  by  exercising  or  operating  a 
system  product  in  which  instrumentation  or  special  test  equipment  is  not  required  beyond  that 
which  is  inherent  to  the  product  and  all  data  required  for  verification  is  obtained  by  observing 
operation  of  the  product. 


72 


Deployment  function  -  The  process  performed  to  take  the  products  of  a  system  or  system  upgrade 
from  the  completion  of  manufacturing  and  verification  to  a  state  of  operational  readiness. 

Derived  requirements  -  Requirements  not  explicitly  stated  in  the  capability  need  but  that  are 

inferred  from  the  nature  of  the  proposed  solution;  the  applicable  verification,  manufacturing, 
rework,  storage,  transportation,  operating,  disposal,  and  support  environments;  policy;  law; 
best  engineering  practice;  or  some  combination  of  the  above. 

Design  -  An  iterative  decisionmaking  process  that  produces  plans  by  which  resources  are  converted 
into  products  or  systems  that  meet  system  requirements. 

Design  constraints  -  Requirements  that  form  boundaries  within  which  other  requirements  must  be 

allocated  or  derived  and  system  products  must  be  designed.  The  constraints  may  be  externally 
imposed — such  as  by  an  interface  with  another  system — or  result  from  decisions  internal  to 
the  program  or  contract. 

Design  release  baseline  -  The  documented,  validated,  and  approved  (1)  design  for  each  system 
product,  including  integrated  assemblies  of  products,  and  (2)  the  definition  of  government 
personnel  manpower  and  skill  levels  necessary  to  operate  and  support  the  system  and  all 
subsequent  changes  thereto  approved  in  accordance  with  the  contract. 

Design  solution  -  The  process  that  translates  the  output  of  the  Requirements  Development  and 
Logical  Analysis  processes  into  alternative  design  solutions  and  selects  the  final  design 
solution. 

Design-to  requirements  -  The  allocated  and  derived  verifiable  technical  requirements  and  design 

constraints  to  which  the  design  of  a  system  product — including  hardware,  software,  processes, 
data,  or  new  or  modified  government  facilities — is  to  comply. 

Developmental  test  and  evaluation  (DT&E)  -  Test  and  evaluation  activities  to  (1)  support 
technology  selection,  requirements  analysis  and  allocation,  and  design  and  (2)  verify 
compliance  with  the  contract  requirements. 

Development  function  -  The  process  performed  to  take  a  system  or  system  upgrade  from  the 
statement  of  the  capability  needs  to  readiness  for  manufacturing,  verification,  training, 
deployment,  operations,  support,  and  disposal  of  the  delivered  system  products.  This  standard 
does  not  require  that  the  development  function  be  addressed  in  defining  the  system  functional 
requirements  or  performing  functional  analysis. 

Disposal  function  -  The  process  performed  to  ensure  that  the  disposition  of  system  products  and  by¬ 
products  that  are  no  longer  needed  or  no  longer  useful  complies  with  applicable  security 
classification  guidance,  demilitarization  policy,  and  environmental  laws  and  regulations. 

Earned  value  management  system  (EVMS)  -  A  system  used  to  measure  the  amount  of  work 

actually  performed  on  a  project  (i.e.,  to  measure  its  progress)  and  to  forecast  a  project’s  cost 
and  date  of  completion. 

Environmental  constraints  or  requirements  -  The  expected  worst-case  impact  of  the  environment 
on  the  system  or  system  product  as  well  as  the  system’s  or  system  products’  allowed  impact 
on  the  environment. 
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External  interface  -  A  design  constraint  comprising  a  boundary  between  a  system  and  another 
system  or  facility. 

Family  of  systems  (FoS)  -  A  set  or  arrangement  of  independent  systems  that  can  be  arranged  or 
interconnected  in  various  ways  to  provide  varying  capabilities.  The  mix  of  systems  can  be 
tailored  to  provide  desired  capabilities,  dependent  on  the  situation. 

Formal  action  -  An  act  that  follows  a  documented  procedure  and  that  is  approved  by  the  signature  of 
an  authorized  individual  recorded  in  a  readily  retrieved  archive. 

Function  -  A  task  to  be  performed  to  achieve  a  required  outcome  or  satisfy  an  operational  need. 

Functional  analysis  and  allocation  -  The  determination  of  the  top-level  functions  that  are  needed  to 
accomplish  the  primary  system  functions  over  the  life  of  the  system,  their  relationship,  and 
their  decomposition  to  subfunctions  to  the  point  that  each  subfunction  or  set  of  subfunctions 
can  be  related  to  one  and  only  one  physical  element  in  the  allocated  baseline,  the  allocation  of 
the  top-level  requirements,  and  constraints  in  the  requirements  baseline  to  determine  how  well 
each  function  and  subfunction  must  be  performed,  and  the  capture  of  the  aggregate  in  a 
functional  architecture. 

Functional  architecture  -  The  result  of  functional  analysis  and  allocation;  the  hierarchical 

arrangement  of  functions,  their  decomposition  into  subfunctions,  the  associated  timelines,  and 
the  allocation  of  the  performance  requirements  and  constraints  in  the  requirements  baseline  to 
the  functions  and  subfunctions. 

Functional  configuration  audit  (FCA)  -  (1)  For  each  configuration  item,  the  formal  examination  of 
its  functional  characteristics  to  verify  that  it  has  achieved  the  requirements  in  its  allocated 
baseline.  (2)  For  a  system,  the  formal  examination  of  its  functional  characteristics  to  verify 
that  it  has  achieved  the  requirements  in  the  functional  baseline. 

Functional  requirement  -  A  task  that  must  be  accomplished  to  provide  a  needed  operational 
capability  (or  satisfy  an  operational  need  or  requirement). 

Hardware  -  System  products  made  of  a  material  substance,  excluding  documentation  (and  not 
including  computer  software). 

Hardware  item  -  An  aggregation  of  hardware  that  satisfies  an  end  use  function  and  is  designated  for 
purposes  of  specification,  interfacing,  qualification,  configuration  management,  or  other 
purposes. 

Implementation  -  The  process  that  yields  the  lowest-level  system  elements  in  the  system  hierarchy. 

Increment  -  A  useful  and  supportable  operational  capability  that  can  be  effectively  developed, 

produced  or  acquired,  deployed,  and  sustained.  Each  increment  of  capability  will  have  its  own 
set  of  threshold  and  objective  values  set  by  the  operator/user. 

Inspection  -  The  verification  method  of  determining  performance  by  examining  (1)  engineering 

documentation  produced  during  development  or  modification  or  (2)  the  system  product  itself, 
using  visual  means  or  simple  measurements  not  requiring  precision  measurement  equipment. 
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Integrated  architecture  (for  interoperability)  -  A  structure  based  on  the  definition  of  architecture 
as  a  structure  of  components,  their  relationships,  and  the  principles  and  guidelines  governing 
their  design  and  evolution  over  time.  Thus  the  integrated  architecture  shows  components  and 
their  relationship  and  needed  capabilities  for  such  key  military  capabilities  as  interoperability 
and  sustainment.  An  architecture  description  is  defined  to  be  an  integrated  architecture  when 
products  and  their  constituent  architecture  data  elements  are  developed  such  that  architecture 
data  elements  defined  in  one  view  are  the  same  (i.e.,  same  names,  definitions,  and  values)  as 
architecture  data  elements  referenced  in  another  view.  The  term  “integrated  architecture” 
refers  to  an  architecture  description  that  has  integrated  operational,  systems,  and  technical 
standards  views.  That  is,  there  are  common  points  of  reference  linking  the  OV  and  the  SV  and 
also  linking  the  SV  and  the  TV. 

Integrated  Master  Plan  (IMP)  -  A  contractual  description  of  the  events,  significant 

accomplishments,  significant  accomplishment  criteria,  applicable  documents,  and  critical 
processes  necessary  to  satisfy  all  contract  requirements.  The  completion  of  each  significant 
accomplishment  is  determined  by  measurable  significant  accomplishment  criteria.  The 
significant  accomplishments  have  a  logical  relationship  to  each  other  (such  as  parallel  or 
sequential)  and,  in  subsets,  prepare  for  events.  Each  event  is,  in  turn,  complete  when  the 
significant  accomplishments  leading  up  to  it  are  complete.  Narratives  that  include  objectives, 
governing  documentation,  and  an  approach  describe  the  critical  processes.  The  IMP  includes 
an  indexing  scheme  (sometimes  called  a  single  numbering  system)  that  links  each  significant 
accomplishment  to  the  associated  CWBS  element,  event,  significant  accomplishment  criteria, 
and  tasks  presented  in  the  Integrated  Master  Schedule  (IMS).  Note:  The  data  in  the  IMP 
defines  the  necessary  accomplishments  for  each  event,  both  for  the  contract  as  a  whole  and  for 
each  team  or  manager  responsible  for  a  specific  CWBS  element. 

Integrated  Master  Schedule  (IMS)  -  The  schedule  showing  the  time  relationship  between  events, 
significant  accomplishments,  and  the  detailed  tasks  required  to  complete  the  contract 
including  calendar  dates,  time  spans,  critical  path,  and  slack.  The  IMS  applies  (and  extends  if 
necessary)  the  same  indexing  (or  single  numbering  system)  as  used  in  the  Integrated  Master 
Plan  (IMP).  IMS  tasks  are  directly  traceable  to  plans  and  accomplishments  of  the  Earned 
Value  Management  System  (EVMS),  though  some  EVMS  plans  or  work  packages  such  as 
those  for  level  of  effort  (LOE)  tasks  need  not  be  traceable  to  the  IMS. 

Integrate-to  requirements  -  Instructions  for  integrating  or  assembling  software  units,  hardware 
pats/assemblies/subassemblies,  hardware  or  software  items,  or  higher-tier  components  to 
build  and  subsequently  verify  still  higher-tier  components  including  the  system.  Part  of  the 
design  release  or  product  configuration  baseline. 

Integration  -  The  process  of  incoiporating  the  lower-level  system  elements  into  a  higher-level 
element  in  the  architecture. 

Interface  -  The  boundary  between  two  or  more  systems,  functions  or  other  logical  representations,  or 
system  products  or  between  a  system  and  a  facility  at  which  interface  requirements  or 
constraints  are  set.  Interfaces  can  be  physical  or  functional. 

Interface  control  -  The  identification,  documentation,  and  control  of  all  interface  requirements  on  a 
system  or  on  the  elements  of  a  system. 
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Interface  control  document;  interface  control  drawing  (ICD)  -  Drawing  or  other  documentation 
that  depicts  interface  designs  or  elements  of  interface  designs  that  satisfy  interface 
requirements. 

Interface  requirements  specification  (IRS),  interface  specification  -  A  repository  for  interface 

requirements  that  details  the  functional  and  physical  relationships  between  systems  or  system 
products  or  between  systems  and  facilities. 

Interoperability  -  The  ability  of  systems,  units,  or  forces  to  provide  data,  information,  materiel,  and 
services  to  and  accept  the  same  from  other  systems,  units,  or  forces  and  to  use  the  data, 
information,  materiel,  and  services  so  exchanged  to  enable  them  to  operate  effectively 
together.  Interoperability  includes  both  the  technical  exchange  of  information  and  the  end-to- 
end  operational  effectiveness  of  that  exchanged  information  as  required  for  mission 
accomplishment. 

Key  performance  parameter  (KPP)  -  An  attribute  or  characteristic  considered  most  essential  for  an 
effective  military  capability. 

Knowledge  database  (or  decision  database)  -  The  linked  and  readily  retrievable  collection  of  data 
(including  inputs  and  intermediate  and  final  results)  that  provide  the  audit  trail  of  decisions 
and  their  rationale  from  the  initial  statement  of  needed  capabilities  or  operational 
requirements  and  design  constraints  to  the  current  description  of  the  system  technical 
requirements  and  the  system  products  (including  facilities  and  processes)  and  government 
personnel  that  collectively  satisfy  the  requirements. 

Life  cycle  -  The  time  scope  of  a  system  from  the  start  of  manufacturing,  verification,  and  integration 
through  deployment,  training,  operations,  and  support  during  all  program  phases,  including 
upgrades,  until  final  disposal  of  the  system  is  complete. 

Life  cycle  cost  (LCC)  -  The  total  cost  to  the  government,  both  sunk  and  anticipated,  of  acquisition 
and  ownership  of  the  system  over  its  useful  life.  It  includes  the  cost  of  research,  development, 
test,  and  evaluation;  procurement  (to  include  production  testing,  deployment,  and  support  to 
initial  operation,  test,  and  evaluation  [10T&E]);  operations  and  support  (to  include  training, 
IOT&E,  and  follow-on  operational  test  and  evaluation  [FOT&E]);  government  facilities;  and 
disposal.  For  defense  systems,  life  cycle  cost  is  also  called  total  ownership  cost  (TOC). 

Like  You  Fly  (LYF)  test  -  A  pre launch  test  based  on  operational  timelines  and  other  applicable 
mission  characteristics. 

Logical  analysis  -  The  process  of  obtaining  sets  of  logical  solutions  to  improve  understanding  of  the 
defined  requirements  and  the  relationships  among  the  requirements,  including  timeline  events 
sequencing,  behavioral,  logical,  and  data  flow  (also  see  functional  analysis  and  allocation). 

Materiel  approach  or  materiel  solution  -  A  defense  acquisition  program  (nondevelopmental, 
modification  of  existing  systems,  or  new  program)  that  satisfies,  or  is  a  primary  basis  for 
satisfying,  identified  warfighter  capabilities.  In  the  case  of  family  of  systems  or  system  of 
systems  (FoS  and  SoS)  approaches,  an  individual  materiel  solution  may  not  fully  satisfy  a 
necessary  capability  gap  on  its  own. 
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Mission  -  The  task  or  tasks  for  which  the  system  is  designed.  Typical  missions  from  space  are: 

communication,  navigation,  Earth  science,  reconnaissance,  missile  warning  and  tracking, 
nuclear  event  detection,  Earth  imaging  for  intelligence,  signals  intelligence,  space  science, 
and  investigating  the  universe. 

Mission  Critical  Fault  Analysis  (MCFA)  -  A  top-down  analysis  that  focuses  on  determining  the 

events  and  sequences  of  events  that  can  lead  to  mission  failure  in  any  phase  of  the  mission  up 
to  and  including  nominal  operations. 

Mission  phase  -  A  portion  of  a  mission  that  has  a  specific  objective  or  set  of  objectives  and  has 

defined  initiation  and  completion  events.  Mission  phases  will  vary  according  to  the  nature  of 
the  mission  area,  but  there  is  likely  to  be  some  commonality  of  phases  between  similar  end 
items.  Typical  mission  phases  for  a  launch  vehicle  are  prelaunch  initialization,  first  stage, 
second  stage,  payload  deployment,  collision  avoidance,  and  reentry.  Typical  mission  phases 
for  a  space  vehicle  are  prelaunch  initialization,  ascent,  separation  and  initialization,  orbit 
transfer,  spacecraft  and  payload  checkout,  nominal  operations,  and  disposal.  Mission  phases 
for  a  command  and  control  system  might  include  test,  training,  rehearsal,  activation,  shadow 
operations,  initial  operations,  contingency  (backup  operations),  maintenance,  and  sustainment. 
There  are  likely  to  be  additional  mission  phases  for  more  complex  missions,  involving 
constellations,  multiple  agencies,  and  multiple  users. 

Nondevelopmental  item  (NDI)  -  Any  system  product  that  is  (1)  available  in  the  commercial 

marketplace  or  (2)  previously  developed  and  in  use  by  a  department  or  agency  of  the  United 
States,  a  state  or  local  government,  or  a  foreign  government  with  which  the  United  States  has 
a  mutual  defense  cooperation  agreement  and  that  does  not  require  unique  upgrades  or 
maintenance  over  its  life  cycle  to  meet  the  current  requirements.  System  products  that  (1) 
have  been  developed  but  are  not  yet  available  in  the  commercial  marketplace  or  in  use  by  a 
government  entity  or  (2)  require  only  minor  modification  or  upgrade  are  termed  near-NDl  (N- 
ND1). 

Objective  -  An  operationally  significant  increment  above  the  threshold;  the  desired  operational  goal 
associated  with  a  performance  attribute,  beyond  which  any  gain  in  utility  does  not  warrant 
additional  expenditure. 

Open  standards  -  Widely  accepted  and  supported  standards  set  by  recognized  standards 

organizations  or  the  market  place.  These  standards  support  interoperability,  portability,  and 
scalability  and  are  equally  available  to  the  general  public  at  no  cost  or  with  a  moderate  license 
fee. 

Operating  conditions  -  The  expected  range  of  operating  variables  when  a  system  or  system  product 
is  performing  as  designed.  Examples  are  temperatures,  motion  of  mechanical  assemblies,  and 
pressures,  such  as  in  propulsion  chambers,  tanks,  and  plumbing. 

Operational  Test  and  Evaluation  (OT&E)  -  Independent  test  used  to  determine  the  effectiveness 
and  suitability  of  the  system  or  system  upgrade  for  operational  use  by  typical  military  users 
and  the  evaluation  of  the  results  of  such  tests.  Can  be  either  initial  (IOT&E)  or  follow-on 
(FOT&E).  IOT&E  is  conducted  on  production  or  production  representative  articles  to  support 
a  decision  to  proceed  with  production  (usually  to  rate  production  if  applicable).  It  is 
conducted  to  provide  a  valid  estimate  of  expected  system  operational  effectiveness  and 
operational  suitability.  FOT&E  is  conducted  during  and  after  the  production  period  to  refine 
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the  estimates  made  during  IOT&E,  to  evaluate  changes,  and  to  reevaluate  the  system  to  ensure 
that  it  continues  to  provide  the  needed  capability  and  retains  its  effectiveness  in  a  new 
environment  or  against  a  new  threat. 

Operations  function  -  The  process  performed  subsequent  to  verification  and  deployment  to 
accomplish  a  system’s  intended  missions,  excluding  training,  support,  and  disposal. 

Operator  -  An  operational  command  or  agency  that  controls  the  acquired  system  for  the  benefit  of 
users.  Operators  may  also  be  users. 

Performance  requirement  -  A  statement  of  the  extent  to  which  a  function  must  be  executed, 

generally  measured  in  such  terms  as  quantity,  quality,  coverage,  timeliness,  or  readiness.  See 
Functional  requirement. 

Physical  configuration  audit  (PCA)  -  (1)  For  each  configuration  item  (Cl),  the  formal  comparison 
of  a  production-representative  article  with  its  design  baseline  to  establish  or  verify  the  product 
baseline.  (2)  For  the  system,  the  formal  comparison  of  a  production-representative  system 
with  its  functional  and  design  baseline  as  well  as  any  processes  that  apply  at  the  system  level 
and  the  formal  examination  to  confirm  that  the  PCA  was  completed  for  each  Cl,  that  the 
decision  database  represents  the  system,  that  deficiencies  discovered  during  testing  (DT&E 
and  IOT&E)  have  been  resolved  and  changes  approved,  and  that  all  approved  changes  have 
been  implemented. 

Physical  hierarchy  -  The  hierarchical  arrangement  of  system  components  necessary  to  satisfy  the 
requirements  baseline  and  to  which  requirements  are  to  be  allocated.  The  top  entry  in  the 
hierarchy  is  the  system.  Intermediate  levels  in  the  hierarchy  include  any  groupings  of 
components  that  are  to  be  integrated  for  any  purpose  (such  as  verification,  manufacturing, 
operations,  or  support)  or  that  are  needed  for  systematic  requirements  allocation.  The 
hierarchy  extends  to  include  all  hardware  and  software  items  necessary  to  satisfy  the 
requirements  baseline  over  the  life  cycle,  whether  deliverable  or  not.  Also  sometimes  called 
the  product  tree  or  the  physical  architecture. 

Preliminary  design  review  (PDR)  -  During  system  development,  the  review  by  the  contractor  and 
the  government  of  (1)  any  changes  to  the  functional  baseline  since  it  was  established,  (2)  the 
functional  architecture,  (3)  the  physical  hierarchy,  (4)  the  allocated  baseline  for  each 
configuration  item,  including  the  completeness  and  compatibility  of  interfaces  between  the 
items  and  between  the  items  and  other  systems,  facilities,  and  personnel,  (5)  the  basis  and  the 
balance  between  performance,  cost,  schedule,  and  risk  for  each  element  in  the  architectures 
and  each  requirement  in  the  baseline,  (6)  the  two-way  traceability  from  the  source  of  the 
functional  baseline  to  the  allocated  baseline  and  back,  and  (7)  the  verification  that  the 
allocated  baseline  can  meet  the  system  requirements. 

Primary  system  functions  -  The  essential  tasks  that  must  be  accomplished  so  that  a  system  will 

provide  the  needed  operational  capability,  implement  DOD  and  military  service  policy,  and 
satisfy  public  law  over  the  life  cycle. 

Process  -  A  procedure  or  treatment  applied  during  the  life  cycle  of  a  system.  The  steps  to  be  taken 
and  any  required  materials,  procedures,  tooling,  or  equipment  are  normally  defined  as  part  of 
the  design  and  controlled  as  part  of  the  design  release  or  product  configuration  baseline. 
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Product  baseline,  product  configuration  baseline  -  The  documented  and  approved  update  to  the 

design  release  baseline  for  one  or  more  system  products  after  confirmation  (1)  of  qualification 
that  the  product  design  satisfies  all  performance  and  functional  requirements  and  constraints 
in  the  current  allocated  and  design  release  baselines,  (2)  that  the  as-built,  as-coded,  or  as- 
integrated  product  is  accurately  reflected  in  the  baselines,  and  (3)  for  hardware  products, 
readiness  for  continued  production,  acceptance  verification,  deployment,  training,  operations, 
support,  and  disposal  and  all  subsequent  changes  thereto  approved  in  accordance  with  the 
contract. 

Product  requirements  analysis  -  The  determination  of  complete  and  verifiable  product  functional 
and  performance  technical  requirements  and  design  constraints.  These  requirements  and 
design  constraints  are  based  on  functional  analysis  and  allocation,  allocation  of  constraints, 
and  derivation  of  further  requirements  and  constraints  toward  the  achievement  of  a  design  that 
satisfies  the  requirements  baseline  and  is  balanced  between  capabilities  to  be  provided  and  the 
evolutionary  growth  potential  on  the  one  hand,  and  cost,  schedule,  and  risk  on  the  other  hand. 
The  results  of  product  requirements  analyses  are  documented  in  the  allocated  baseline. 

Qualification  -  (1)  For  hardware,  the  verification  that  a  hardware  item  or  higher  level  of  integration, 
together  with  its  embedded  software,  meets  all  requirements  and  constraints  of  the 
environmental  and  operating  conditions  anticipated  over  its  life  cycle,  including  specified 
margin  to  the  maximum  predicted  flight  environment  (MPE);  (2)  for  software,  the  verification 
that  a  software  unit  meets  all  requirements  and  constraints  using  operationally  representative 
data  in  an  operationally  representative  configuration. 

Requirement  -  ( 1 )  A  condition  or  capability  needed  by  a  user  to  solve  a  problem  or  achieve  an 

objective;  (2)  a  condition  or  capability  that  must  be  met  or  possessed  by  a  system  or  system 
component  to  satisfy  a  contract,  standard,  specification,  or  other  formally  imposed  documents; 
(3)  a  documented  representation  of  a  condition  or  capability  as  in  (1)  or  (2). 

Requirement  reference  -  A  higher-level  requirement  and/or  an  analysis,  test,  or  other  justification 
for  a  requirement,  requirement  allocation,  or  other  baseline  or  functional  architecture  element. 

Requirements  acceptability  criteria  -  Requirements  that  define  a  system  that  satisfies  all  user 
capabilities  and  requirements.  All  user  requirements  trace  to  system-  and  lower-level 
requirements. 

Requirements  analyses  -  The  determination  of  complete  and  verifiable  system  functional  and 

performance  technical  requirements  and  design  constraints  based  on  analyses  of  the  needed 
operational  capabilities,  requirements,  objectives  (or  goals),  measures  of  effectiveness; 
missions;  and  projected  utilization  environments;  DOD  policies  and  practices;  public  law;  and 
the  balance  between  capabilities  to  be  provided  and  the  evolutionary  growth  potential  on  the 
one  hand,  and  cost,  schedule,  and  risk  on  the  other  hand.  The  results  of  requirements  analyses 
are  documented  in  the  requirements  baseline. 

Requirements  baseline  -  The  documented,  validated,  and  approved  system-level  (top-level) 
verifiable  and  allocable  functional  and  performance  technical  requirements  and  design 
constraints,  their  allocation  or  assignment  to  the  lower  levels  necessary  to  capture  the  systems 
engineering  foundation  for  the  program,  and  all  changes  thereto  approved  in  accordance  with 
the  contract. 
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Requirements  development  -  The  process  of  taking  all  inputs  from  relevant  stakeholders  and 
translating  those  inputs  into  technical  requirements. 

Risk  -  The  uncertainty  of  attaining  a  requirement,  goal,  or  objective  pertaining  to  technical 
performance,  schedule,  or  cost  and  the  consequences  of  not  attaining  it. 

Significant  accomplishment  -  A  specified  step  or  result  that  indicates  a  level  of  progress  toward 
completing  an  event  and,  in  turn,  meeting  the  objectives  and  requirements  of  the  contract. 

Significant  accomplishment  criteria  -  Specific,  measurable  conditions  that  must  be  satisfactorily 

demonstrated  before  a  significant  accomplishment  listed  in  an  Integrated  Master  Plan  (IMP)  is 
complete  and  before  work  dependent  on  the  accomplishment  can  proceed. 

Software  -  Computer  programs,  procedures,  and  data  pertaining  to  the  operation  of  a  computer 

system.  Data  may  include,  for  example,  information  in  databases,  rule  bases,  or  configuration 
data.  Procedures  may  include,  for  example,  interpreted  scripts. 

Software  item  -  An  aggregation  of  software  that  satisfies  an  end  use  function  and  is  designated  for 
the  purposes  of  specification,  interfacing,  qualification  testing,  configuration  management,  or 
other  purposes.  A  software  item  is  composed  of  one  or  more  software  units.  A  software  item 
is  sometimes  called  a  computer  software  configuration  item  (CSC1). 

Software  unit  -  An  element  in  the  design  of  a  software  item;  for  example,  a  major  subdivision  of  a 
software  item,  a  component  of  that  subdivision,  a  class,  object,  module,  function,  routine,  or 
database.  A  software  unit  is  sometimes  called  a  computer  software  unit  (CSU). 

Specification  -  A  description  of  the  verifiable  technical  requirements  and  design  constraints  for 

hardware  and  computer  software,  materials,  and  processes,  along  with  the  verification  method 
for  determining  whether  each  requirement  is  met. 

Support  function  -  The  process  performed  to  facilitate  uninterrupted  operations  and  training.  The 
tasks  include  the  acquisition  and  supply  of  spares,  depot-level  maintenance,  the  acquisition 
and  maintenance  of  the  facilities,  and  selection  and  training  of  personnel. 

Survivability  -  The  capability  of  a  system  to  avoid  or  withstand  man-made  hostile  environments 
without  suffering  an  abortive  impairment  of  its  ability  to  accomplish  its  designated  mission. 

System  -  An  integrated  set  of  products  (to  include  processes  and  government  facilities)  and  personnel 
that  interact  with  one  another  in  an  organized  or  interrelated  fashion  toward  a  common 
purpose  that  cannot  be  achieved  by  any  of  the  products  alone  or  by  all  of  the  products  without 
the  underlying  organization.  The  integrated  products  and  personnel  fulfill  manufacturing, 
verification,  integration,  deployment,  training,  operations,  support,  and  disposal  functions  to 
provide  needed  operational  capabilities  or  satisfy  objectives. 

System  concept  -  A  rudimentary  or  unfinished  design  used  for  preliminary  assessments  of  system 
effectiveness,  cost,  schedule,  or  risk  that  provides  the  basis  for  more  detailed  designs  through 
further  iteration  of  the  requirements,  functional,  and  design  analyses  as  required  by  this 
standard. 
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System  functional  review  (SFR)  -  A  review,  usually  held  prior  to  or  early  in  the  design  or  similar 
phase,  by  the  developer  and  the  customer  to  confirm  that  (1)  technology  maturity  has  been 
demonstrated  and  the  risk  reduction  efforts  planned  prior  to  the  start  of  design  have  been 
completed  and  the  results  have  been  reflected  in  the  proposed  requirements  baseline  and 
preliminary  allocated  baseline,  (2)  requirements  analysis  has  progressed  to  the  point  that  the 
proposed  requirements  baseline  is  accurate  and  comprehensive  (though  perhaps  with  TBDs, 
TBRs,  and  TBSs),  (3)  the  preliminary  allocated  baseline  reflects  the  proposed  requirements 
baseline  and  is  balanced  with  respect  to  performance,  cost,  schedule,  risk,  and  potential  for 
evolutionary  growth,  (4)  the  decision  database  supports  two-way  traceability  from  the  source 
of  the  requirements  baseline  to  the  preliminary  allocated  baseline  and  from  any  element  to  the 
rationale  for  that  element,  (5)  the  assessment  that  the  evolving  allocated  baseline  can  lead  to  a 
design  that  will  satisfy  the  requirements  baseline,  (6)  the  preliminary  physical  hierarchy,  the 
planned  (or  approved)  PWBS,  and  the  CWBS  in  place  or  proposed  to  be  used  subsequent  to 
the  SFR  are  all  consistent,  (7)  the  life  cycle  cost  for  the  evolving  design  is  consistent  with  the 
program  affordability  constraints,  and  (8)  the  remaining  risks  have  been  identified  and  can  be 
handled  in  the  context  of  the  planned  contract  and  program  activities.  The  primary  SFR  data  is 
the  decision  database  documenting  or  demonstrating  that  these  systems  engineering 
requirements  have  been  satisfied. 

System  effectiveness  -  Objective,  quantifiable  measure(s)  (such  as  communications  throughput, 

surveillance  sensitivity,  or  navigation  accuracy)  that  relate  the  system  concept  or  design  to  the 
system  technical  functional  and  performance  requirements  and  constraints. 

System  of  systems  (SoS)  -  A  set  or  arrangement  of  interdependent  systems  that  are  related  or 

connected  to  provide  a  given  capability.  The  loss  of  any  part  of  the  system  will  degrade  the 
performance  or  capabilities  of  the  whole. 

System  product  -  A  separately  identifiable  portion  of  a  system  other  than  personnel,  whether 
delivered  or  not,  to  include  hardware,  software,  firmware,  process,  government 
facility/equipment  or  modification  of  an  existing  government  facility/equipment,  modification 
to  existing  equipment  or  property,  document,  manual,  drawing,  instructions,  data,  or 
combination  thereof.  Services  that  are  not  system  products  but  data  that  defines  the  required 
scope  of  services  such  as  contractor  support  during  10T&E  or  operations  are  system  products. 

System  requirements  review  (SRR)  -  A  review,  usually  held  near  the  end  of  the  program  definition 
and  risk  reduction  or  similar  phase  (Phase  1),  by  the  contractor  and  the  government  to  confirm 
that  (1)  the  planned  risk  reduction  efforts  are  making  adequate  progress  and  reflect  the 
technologies  envisioned  to  implement  the  preferred  system  concept(s),  (2)  the  operational 
requirements  and  objectives  have  been  accurately  and  comprehensively  translated  into 
technical  requirements  and  are  reflected  in  the  preliminary  functional  baseline,  (3)  the 
preliminary  functional  baseline  and  the  plans  to  complete  it  account  for  the  eight  primary 
functions  and  all  design  constraints  on  the  system  design,  (4)  the  preliminary  physical 
hierarchy  is  consistent  with  the  preliminary  functional  baseline,  (5)  life  cycle  cost  projections 
remain  consistent  with  the  program  affordability  constraints,  (6)  the  decision  database 
supports  two-way  traceability  from  the  source  of  the  functional  baseline  to  the  functional 
baseline  and  from  any  element  to  the  rationale  for  that  element  and  shows  the  rationale  and 
approval  authority  for  all  changes,  and  (8)  the  significant  accomplishments  and 
accomplishment  criteria  have  been  planned  for  the  next  wave  of  technical  activity  on  the 
contract. 
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System  technical  requirements  -  Characteristics,  attributes,  or  distinguishing  features  stated  in 
terms  of  verifiable  functional  and  performance  requirements  and  design  constraints  that  a 
system  or  system  element  must  have  within  a  defined  environment  or  set  of  conditions, 
including  the  threat,  in  order  to  provide  a  needed  operational  capability  and  comply  with 
applicable  decisions  by  the  milestone  decision  authority,  policy,  practices,  and  law.  The 
system  technical  requirements  are  documented  in  the  requirements  baseline.  Technical 
requirements  for  the  elements  of  the  system  are  allocated  from  the  requirements  baseline. 

System  threat  assessment  -  Describes  the  threat  to  be  countered  and  the  projected  threat 

environment.  The  threat  usually  depends  on  the  technical  characteristics  of  the  design 
solution. 

System  Threat  Assessment  Report  (STAR)  -  An  intelligence  document  validated  by  the  Defense 
Intelligence  Agency  (D1A)  that  serves  as  the  single  authoritative  reference  for  threat  data  to 
be  used  in  a  weapon  system  acquisition  program.  The  STAR  contains  the  lethal  and  nonlethal 
threats  against  the  system  and  the  threat  environment  in  which  the  system  will  operate. 

System  verification  review  (SVR)  -  A  review,  usually  held  near  the  end  of  development  and  prior  to 
production,  by  the  contractor  and  the  government  to  confirm  that  (1)  the  system  and  its 
constituent  products  have  been  verified  to  satisfy  the  requirements,  allocated,  and  design 
release  baselines,  including  an  assessment  of  the  assumptions  and  methods  used  in 
verification  by  analysis,  (2)  deficiencies  discovered  during  verification  (DT&E)  (and 
validation — 10T&E — to  the  extent  completed)  have  been  resolved  and  changes  approved  and 
implemented,  (3)  all  other  approved  changes  have  been  incorporated  into  the  affected 
baselines  and  the  affected  system  products  verified  to  comply,  (4)  the  life  cycle  cost 
projections  remain  consistent  with  the  program  affordability  constraints,  (5)  the  requisite 
plans,  procedures,  resources,  and  facilities  are  available  (or  on  schedule)  to  initiate 
production,  production  verification,  training,  deployment,  operations,  support,  and  disposal, 

(6)  the  remaining  risks  have  been  identified  and  can  be  handled  in  the  context  of  the  planned 
program,  and  (7)  the  decision  database  has  been  maintained  to  capture  all  changes  and 
updates  so  that  it  completely  and  accurately  captures  (a)  the  current  approved  baselines  and 
(b)  the  verification  data  showing  compliance  with  the  baselines.  The  primary  data  for  the  SVR 
is  the  decision  database  documenting  or  demonstrating  that  these  systems  engineering 
requirements  have  been  satisfied. 

Systems  engineering  -  As  a  process,  service,  function,  or  activity,  an  interdisciplinary  effort  to 
iteratively  and  recursively  (1)  support  the  evolution  of,  first,  the  integrated  architectures, 
roadmaps,  capability  assessments,  and  Initial  Capabilities  Document  (ICD),  and  then  later,  the 
Capabilities  Development  Document  (CDD)  and  Capabilities  Production  Document  (CPD)  to 
guide  the  development  program,  (2)  translate  the  needed  capabilities  and  objectives  into,  first, 
a  requirements  baseline,  second,  an  allocated  baseline,  third,  a  design  release  baseline,  and, 
finally,  a  product  configuration  baseline,  all  of  which  collectively  provide  a  design  response 
to  the  capability  needs  that  is  balanced  with  respect  to  system  effectiveness,  cost,  schedule, 
risk  and  evolutionary  growth  potential,  (3)  maintain  those  baselines  over  the  life  cycle  of  the 
system,  (4)  assess  compliance  with  the  baselines  as  development  evolves,  and  (5)  verify  that 
the  baselines  have  been  met  by  products  built,  coded,  bought,  and  integrated  in  accordance 
with  the  design,  and  then  support  the  validation  (through  OT&E)  that  the  needed  capabilities 
have  been  provided. 
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Systems  engineering  plan  (SEP)  -  Government  document  that  specifies  the  scope  of  the  technical 
effort  required  to  develop  and  sustain  the  system  or  solution  through  its  entire  life  cycle.  At  a 
minimum,  the  planning  effort  must  define  the  government,  contractor,  and  subcontractor  tasks 
that  will  be  accomplished;  the  allocation  of  responsibilities;  what  resources  are  needed;  and 
how  SE  activities  will  be  monitored,  controlled,  and  integrated  with  the  other  aspects  of  the 
program.  The  SEP  guides  all  technical  aspects  of  the  program.  These  plans  are  tied  together  in 
the  program’s  Integrated  Master  Plan  (IMP)  and  Integrated  Master  Schedule  (IMS). 

Systems  engineering  product  -  A  tangible  and  documented  result  of  systems  engineering  to  include 
plans,  tradeoff  and  other  analyses,  the  baselines,  the  functional  architecture,  assessments, 
drawings,  instructions,  verification  data,  or  validation  results. 

Systems  engineering  requirement  -  Statement  describing  a  mandatory  contract  compliance  element, 
attribute,  or  quality  of  the  systems  engineering  activity. 

System(s)  view,  system  architecture  view  (SV)  -  A  description,  including  graphics,  of  system(s) 
and  interconnections  providing  for,  or  supporting,  DOD  functions.  DOD  functions  include 
both  warfighting  and  business  functions.  (1)  For  a  domain,  the  SV  shows  how  multiple 
systems  link  and  interoperate  in  terms  of  the  high-level  internal  construction  and  operations  of 
particular  systems  within  the  architecture.  (2)  For  the  individual  system,  the  SV  emphasizes 
the  physical  connection,  location,  and  identification  of  key  hardware  and  software;  it  may  also 
include  data  stores,  circuits,  and  networks  and  may  specify  system  and  component 
performance  parameters  to  show  how  the  individual  system  supports  the  broader  capabilities 
shown  in  the  domain  SV  and  any  associated  operational  views  (OVs).  The  SV  associates 
resources  to  the  operational  view  (OV)  and  its  requirements  per  standards  defined  in  the 
technical  view  (TV);  see  the  definitions  of  these  terms.  See  also  integrated  architecture. 
Several  systems  engineering  products  have  been  defined  making  up  the  SV;  see  Section  5  of 
the  DOD  Architecture  Framework,  Volume  II,  15  January  2003. 

Tailoring  -  The  modification  of  text,  figures,  graphs,  tables  of  specifications,  standards,  or  other 
requirements  or  tasking  documents  to  clarify  the  extent  to  which  they  are  applicable  to  a 
specific  acquisition  contract. 

TBD/TBR/TBS  -  TBD:  “to  be  determined”  by  the  developer  (or  formally  recommended  to  the 

customer)  based  on  analysis  or  test  by  a  stated  and  documented  date.  TBR:  the  preliminary 
element  is  “to  be  resolved”  by  the  developer  (or  recommended  to  the  customer)  based  on 
analysis  or  test  by  a  stated  and  documented  date.  TBS:  “to  be  supplied”  by  the  customer  to  the 
developer  by  an  agreed-to  and  documented  date. 

Technical  performance  measure  (TPM)  -  A  measure  comparing  the  current  actual  achievement  for 
technical  parameters  with  that  anticipated  at  the  current  time  and  on  future  dates.  Confirms 
progress  and  identifies  deficiencies  that  might  jeopardize  meeting  a  system  requirement. 
Assessed  values  falling  outside  the  expected  range  indicate  a  need  for  evaluation  and 
corrective  action. 

Test  -  The  verification  method  of  determining  performance  by  exercising  or  operating  the  system  or 
system  product  using  instrumentation  or  special  test  equipment  that  is  not  an  integral  part  of 
the  system  or  system  product  being  verified. 
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Test  and  evaluation  master  plan  (TEMP)  -  A  plan  that  correlates  and  integrates  T&E  with  the 

overall  acquisition  program  strategy,  schedule,  and  other  program  documentation,  and  defines 
the  critical  path  for  completing  test  and  evaluation.  The  TEMP  will  place  the  most  emphasis 
on  the  next  phase  of  system  development  rather  than  provide  a  historical  account  of  program 
progress.  The  TEMP  is  usually  updated  prior  to  major  milestones,  program  baseline  changes, 
or  when  there  have  been  significant  changes  to  the  program. 

Test  plan  -  Documented  approach,  resources,  and  schedule  to  verify  compliance  of  a  system  or  one 
of  its  elements  by  test  or  to  obtain  data  to  support  a  contract  or  program  decision. 

Test  procedure  -  Documented  list  of  equipment,  manuals,  and  other  required  material  and 
instructions  to  perform  a  test. 

Test  report  -  Documentation  of  compliance  with  the  test  plan  and  the  compliance  or  noncompliance 
of  the  system  products  under  test. 

Threshold  -  A  minimum  acceptable  operational  value  below  which  the  utility  of  the  system  becomes 
questionable. 

Total  ownership  cost  (TOC)  -  Costs  to  research,  develop,  acquire,  own,  operate,  and  dispose  of 

defense  systems,  other  equipment,  and  real  property;  the  costs  to  recruit,  retain,  separate,  and 
otherwise  support  military  and  civilian  personnel;  and  all  other  costs  of  the  business 
operations  of  the  DOD.  At  the  individual  program  level,  total  ownership  cost  is  synonymous 
with  the  life  cycle  cost  of  the  system.  See  lifecycle  cost. 

Traceability  -  The  ability  to  relate  an  element  of  the  requirements  baseline,  functional  architecture, 
allocated  baseline,  design  release  baseline,  and  product  configuration  baseline  (or  their 
representation  in  the  decision  database)  to  any  other  element  to  which  it  has  a  master- 
subordinate  (or  parent-child)  relationship. 

Tradeoff,  tradeoff  study  -  An  objective  comparison  with  respect  to  system  effectiveness,  cost, 
schedule,  risk,  and  potential  for  evolutionary  growth  of  all  feasible  alternative  system 
requirements,  functional  architectures,  allocated  baselines,  or  designs.  Can  be  used  as  the 
basis  for  selecting  less  capability  in  one  area  in  order  to  achieve  a  more  balanced  overall 
system  result. 

Trade  space  -  The  set  or  range  of  feasible  alternatives  to  be  compared  to  achieve  a  solution  that  is 
balanced  with  respect  to  system  effectiveness,  cost,  schedule,  risk,  and  potential  for 
evolutionary  growth. 

Training  function  -  The  process  performed  to  achieve  and  maintain  knowledge  and  skill  levels 

necessary  to  perform  the  operations,  support,  and  disposal  functions  efficiently  and  effectively 
over  the  system  life  cycle. 

Transition  -  The  process  of  moving  the  system  element  to  the  next  level  in  the  physical  architecture 
or,  for  the  end-item  system,  the  user. 

User  -  An  operational  command  or  agency  that  receives  or  will  receive  benefit  (e.g.,  data  or  services) 
from  the  acquired  system  when  it  is  in  operation. 
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Validation  -  (1)  For  a  baseline,  the  demonstration  that  it  has  its  required  attributes,  that  any 

assumptions  necessary  in  its  development  are  valid,  and  that  the  effectiveness  of  the  emerging 
system  design  will  satisfy  the  system  technical  requirements  and  constraint;  (2)  for  a  satellite 
or  launch  system,  the  certification  that  it  is  ready  for  launch;  (3)  for  any  other  system,  the 
assessment  of  the  operational  test  authority  that  the  system  is  suitable  for  operations  and 
continued  production,  if  planned. 

Verifiable  -  Confirmable,  capable  of  being  tested  (verified  or  falsified)  by  experiment  or  observation. 

Verification  -  The  process  that  confirms  that  the  system  and  its  elements  meet  the  design-to  or  build- 
to  specification. 

Verification  method  -  A  finite,  objective,  reproducible  way  to  prove  that  a  solution  meets  a 

requirement.  The  verification  methods  are  test,  demonstration,  inspection,  and  analysis. 

Work  Breakdown  Structure  (WBS)  -  A  system  product-oriented  hierarchical  tree  composed  of  the 
hardware  to  be  developed,  produced,  or  sustained;  software  to  be  developed  or  sustained; 
services  (including  cross-product  activities  such  as  systems  engineering);  data;  and  facilities 
that  encompass  all  work  to  be  carried  out  under  the  program  or  contract  along  with  a 
dictionary  of  the  entries  in  the  tree.  The  WBS  for  the  entire  program  is  called  the  program  or 
project  WBS  (PWBS).  The  WBS  for  the  work  under  a  contract  is  called  the  contract  WBS 
(CWBS)  and  is  prepared  in  accordance  with  the  contract. 
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APPENDIX  D: 

HUMAN  SYSTEMS  INTEGRATION  PLAN 

The  following  data  item  has  been  developed  to  provide  improved  clarity  for  efficient  planning  of  an 
effective  and  affordable  human  systems  integration  effort.  This  data  item  comprises  a  tailoring  of  the 
currently  approved  Data  Item  Description,  DI-HFAC-81743A.  Use  of  this  data  item  is  highly 
recommended  if  not  specified  as  a  contractually  deliverable  or  accessible  item. 

DI-HFAC-8 1 743 A/T  (SMC) 

DATA  ITEM  DESCRIPTION 

Title:  HUMAN  SYSTEMS  INTEGRATION  PLAN 

Number:  DI-HFAC-8 1743 A/T  (SMC)  Approval  Date:  TBA 

AMSC  Number:  N/A  Limitation:  N/A 

DTIC  Applicable:  N/A  GIDEP  Applicable:  N/A 

Office  of  Primary  Responsibility:  SMC/EN  Applicable  Forms:  N/A 

Use/Relationship:  The  Human  Systems  Integration  Plan  (HSIP)  describes  the  contractor’s  Human 
Systems  Integration  (HSI)  efforts;  elements  and  activities  supporting  HSI  domain  requirements 
specified  in  the  contract  and  any/all  associated  derived  requirements;  and  how  they  will  be  managed 
and  integrated  with  other  program  elements.  The  HSIP  does  not  take  the  place  of  domain-specific 
plans  such  as  the  System  Safety  Plan;  Training  Plan;  Programmatic  Environment,  Safety,  and 
Occupational  Health  Evaluation;  Human  Engineering  Program  Plan  (HEPP);  or  an  HSI  section  in  the 
Systems  Engineering  Management  Plan,  unless  the  procuring  agency  so  directs. 

a.  This  Data  Item  Description  (DID)  contains  the  format  and  instructions  for  preparing  the 
HSIP  content  in  response  to  applicable  tasks  delineated  in  the  contract  Statement  of  Work  (SOW). 

b.  Where  cited  below,  users  refer,  as  applicable,  to  operators,  maintainers,  trainers,  support 
personnel  (including  transporters),  and  manufacturers. 

c.  This  SMC  tailored  DID  supersedes  DI-HFAC-8 1743 A,  dated  20110421. 

d.  For  SMC  contracts  the  HSIP  shall  be  a  separate  plan  and  shall  be  summarized  and 
referenced  in  the  SEMP. 

Requirements: 

1 .  Compliance  and  Reference  documents.  The  applicable  issue  of  the  documents  cited  herein, 
including  their  approval  dates  and  dates  of  any  applicable  amendments,  notices,  and  revisions,  shall 
be  as  cited  in  the  Acquisition  Streamlining  and  Standardization  Information  System  (ASSIST) 
database  at  the  time  of  the  solicitation,  or  as  cited  in  the  SOW  of  the  request  for  proposal  (RFP)  or 
contract. 

2.  Format.  The  HSIP  format  shall  be  contractor  selected  and  contain  all  the  content  elements 
described  below  as  tailored  per  paragraph  3.  The  format  used  initially  shall  be  used  for  subsequent 
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submissions.  Revisions  shall  be  clearly  indicated  in  a  manner  consistent  with  standard  editorial 
practices. 

3.  Tailoring.  The  HS1P  shall  be  tailored  to  reflect  the  Statement  of  Work  (SOW),  system 
specification,  and  phase  of  development.  The  proposed  tailoring  of  the  HS1P  content  shall  identify  the 
paragraph,  proposed  changes,  and  rationale  for  the  change(s).  Tailoring  specified  by  the  procuring 
agency  shall  also  be  included.  If  no  tailoring  is  proposed  beyond  that  specified  by  the  procuring 
agency,  this  shall  be  stated. 

4.  Content.  The  HS1P  shall  contain  the  information  described  in  the  following  paragraphs. 

(a)  Front  matter.  Table  of  contents;  lists  of  tables,  figures,  and  appendices,  as  applicable;  and  a  list  of 
acronyms  and  abbreviations. 

(b)  Overview. 

i.  Provide  the  HSIP  purpose  and  scope.  Briefly  describe  the  system,  its  concept  of  operations, 
mission,  human  role(s),  operational  environment,  predecessor  system(s),  if  any,  and  related  HS1 
lessons  learned.  Provide  the  system  acquisition  category  and  current  phase  of  development.  Reference 
other  program  documents  that  may  provide  additional  detail,  as  appropriate.  If  applicable,  state  when 
the  next  submission  of  the  HSIP  is  due. 

ii.  Describe  the  overall  HS1  objectives  for  the  program,  the  HS1  domains  that  will  be 
addressed,  and  the  strategy  for  addressing  HS1  domain  objectives  individually  and  in  domain  trade 
studies.  The  HS1  Domains  shall  comprise  the  nine  (9)  domains  defined  in  AF1  63-1201,  Attachment  5 
(2011),  AF1  63-101  (2010)  Section  3.79,  and/or  the  Air  Force  Human  Systems  Handbook.  Each  of 
the  HSI  domains  shall  be  individually  and  specifically  addressed.  If  any  HS1  domains  will  not  be 
addressed,  provide  a  rationale  for  the  exclusion.  Briefly  describe  the  major  activities  that  must  be 
accomplished  in  applying  HSI  to  the  system  development,  consistent  with  the  contract  SOW,  system 
requirements,  specification(s),  and  work  breakdown  structure. 

iii.  Provide  a  list  of  HSl-related  contract  deliverables  or  accessible  documents  (e.g.,  Training 
Plan,  Safety  Plan,  Manpower  Estimate)  for  all  domains  deemed  applicable  in  task  4.b.ii.  For  any 
section  below  whose  content  is  substantially  covered  in  another  document,  the  contractor  has  the 
option  of  providing  the  required  content  in  the  HSIP  or  providing  a  summary  of  the  content  and 
referencing  the  document  section(s)  that  contains  the  content. 

(c)  Organization. 

i.  Human  Systems  Integration  organization.  Identify,  describe,  and  provide  an  organizational 
chart  of  the  contractor’s  primary  organization  elements(s)  and  primary  HSI  organization  elements, 
including  the  HSI  Integrated  Product  Team,  if  any.  Identify  the  HSI  domain(s)  addressed  by  each 
element;  to  whom  the  HSI  manager/lead  and  HSI  domain  leads  report;  and  the  reporting  and 
responsibility  relationships  between  the  HSI  manager/lead  and  the  HSI  domain  leads.  For  key 
positions  (e.g.,  HSI  manager/lead,  domain  leads,  key  practitioners),  provide  summary  job  descriptions 
and  the  minimum  required  qualifications. 

ii.  Human  Systems  Integration  organizational  relationships.  Describe  the  relationships  and 
responsibilities  of  the  contractor’s  HSI  organization  element(s)  to  other  contractor  organization 


elements  responsible  for  areas  affected  by  HS1,  such  as  systems  engineering;  hardware  and  software 
design  teams;  training;  test  and  evaluation;  related  disciplines  (e.g.,  reliability,  maintainability, 
supportability);  applicable  working  groups;  and  government  HSI  counterparts. 

iii.  Human  Systems  Integration  working  group.  Describe  the  composition  of  the  HSI  working 
group  (e.g.,  contractor,  subcontractor,  and  procuring  agency  HSI  domain  representatives  and  user 
group  representatives),  and  its  responsibility,  authority,  and  accountability  for  ensuring  compliance 
with  HSI  requirements.  Provide  a  charter  for  the  working  group. 

(d)  Human  Systems  Integration  Key  Performance  Parameters  and  Key  System  Attributes.  Describe 
Key  Performance  Parameters  (KPPs)  and  Key  System  Attributes  (KSAs)  with  HSI  implications 
considering  all  HSI  domains  deemed  applicable  in  task  4.b.ii,  above. 

(e)  Human  Systems  Integration  support  of  affordability  and  performance  goals.  Describe  the 
method(s)  by  which  the  contractor  will  identify  and  conduct  tradeoffs  between  HSI  domains  and 
other  program  elements  in  support  of  primary  HSI  goals:  to  reduce  total  system  ownership  costs; 
improve  total  system  performance;  and  ensure  that  the  system  accommodates  the  characteristics  of 
the  user  population  that  will  design,  develop,  manufacture,  operate,  maintain,  train,  and  support  it. 
Describe  how  the  contractor  will  ensure  that  HSI  cost  and  performance  factors  will  be  formally 
considered  during  analysis,  design,  and  procedure  development;  during  technical  reviews  (e.g., 
system  requirements  review,  systems  functional  review,  preliminary  design  review,  or  critical  design 
review);  and  in  the  engineering  change  management  process. 

(f)  Human  Systems  Integration  issues  and  risks.  Describe  the  method(s)  by  which  the  contractor  will 
identify,  document,  validate,  prioritize,  coordinate,  track,  report,  and  resolve  or  mitigate  HSI  issues 
and  risks  over  the  life  of  the  program.  Describe  the  process  for  trading  off  HSI  issues  and  risks  among 
HSI  domains,  and  between  HSI  and  other  disciplines.  Describe  the  process  by  which  HSI  risks  will  be 
elevated  to  formal  program-level  risk  management  status. 

(g)  Human  Systems  Integration  in  subcontractor  or  interorganizational  efforts.  If  subcontractors, 
including  work  transferred  to  other  coiporate  divisions  and  the  like,  are  responsible  for  work  on 
hardware  or  software  components  that  have  operator,  maintainer,  or  supporter  interfaces,  or  other  HSI 
efforts  (e.g.,  serving  as  subject  matter  experts,  performing  trade  studies),  describe  the  subcontractor’s 
organization  element  responsible  for  HSI  and  the  subcontractor’s  HSI  activities.  Describe  the  process 
by  which  requirements  for  HSI  will  be  levied,  implemented,  and  integrated  across  subcontractors  for 
all  HSI  domains.  Describe  the  method(s)  by  which  the  prime  contractor  will  monitor  subcontract 
compliance  with  HSI  requirements. 

(h)  Human  Systems  Integration  in  system  analysis.  Identify  the  HSI  efforts  in  system  analysis  and  the 
organizational  element(s)  responsible  for  their  conduct.  Describe  how  HSI  domain  area  practitioners 
or  subject  matter  experts  will  participate  in: 

1 .  Analyzing,  flowing  down,  aligning,  and  deriving  requirements. 

2.  Performing  mission  analysis. 

3.  Determining  system  functional  requirements  and  capabilities. 

4.  Determining  system  architecture. 

5.  Allocating  system  functional  requirements  to  humans,  hardware,  and/or  software. 
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6.  Developing  system  functional  flows. 

7.  Performing  system  effectiveness  analyses,  studies,  and  modeling. 

List  the  HS1  analyses  that  will  be  performed  to  support  system  definition  for  all  domains  (e.g., 
manpower  estimation,  critical  function  analysis).  For  each  analysis: 

1 .  Provide  a  description  or  a  reference  to  the  paragraph(s)  where  it  is  described  elsewhere  in 
the  HS1P  or  other  document(s). 

2.  Identify  any  data,  software,  databases,  models,  or  equipment  required  from  the  procuring 

agency. 

(i)  Human  Systems  Integration  in  system  design.  Describe  the  HSI  effort  (for  all  applicable  domains) 
in  system  design  to  ensure  fulfillment  with  the  requirements  and  guidance  documents  for  HSI 
specified  in  the  contract.  Describe  HSI  domain  area  practitioner  or  subject  matter  expert  participation 
in: 


1.  The  preparation  of  system  design  and  performance  specifications. 

2.  Selection  of  commercial  off-the-shelf  or  nondevelopmental  items. 

3.  Trade  studies  and  analyses. 

4.  Mock-up  evaluations  and  dynamic  simulations. 

5.  Usability  assessments. 

6.  Tests. 

7.  Detailed  drawing  reviews. 

8.  System  and  program  technical  reviews. 

Describe  the  planned  involvement  of  (and  coordination  to  obtain)  end-user  personnel  (e.g.,  operators, 
maintainers,  trainers,  and  support  personnel)  in  assessing  the  design,  operation,  maintenance,  training, 
and  support  of  the  system.  Describe  and  provide  a  rationale  for  the  methodology  and  human 
performance  criteria  to  be  used. 

(j)  Human  Systems  Integration  in  procedure  development.  Describe  the  HSI  domain  area  practitioner 
or  subject  matter  expert  role  in  creating,  reviewing,  and  validating  procedures  for  users.  This  involves 
activities  such  as  developing  operator  manuals,  interactive  electronic  technical  manuals,  and  training 
media. 

(k)  fReservedl 

(l)  [Reserved! 

(m)  [Reserved! 

(n)  [Reserved! 

(o)  [Reserved! 


90 


(p)  Human  Systems  Integration  in  verification  and  validation.  Describe  HSI  domain  area  practitioner 
or  subject  matter  expert  participation  in  the  contractor’s  integrated  test  and  evaluation  program, 
including  developmental  (DT),  operational  (OT),  and/or  combined  DT/OT  planning  or  test  execution. 
Describe  how  (e.g.,  methods,  metrics,  and  tools)  and  when  the  contractor  will  verify  the  design  for 
compliance  with  HSI  requirements.  Identify  the  number  and  role(s)  of  HSI  personnel  who  will 
support  test  and  evaluation.  Provide  a  summary  schedule  that  depicts  HSI  tests,  evaluations,  and  other 
verification  activities  (inspections,  analyses,  and  demonstrations)  in  support  of  program  milestones. 

(q)  Data  sources.  Identify  contractor,  industry,  technical  society,  and  government  standards, 
handbooks,  and  other  documents  that  will  be  applied  to  HSI  domain  integration  activities  and  any 
proposed  tailoring. 

(r)  Human  Systems  Integration  data  products.  Identify  and  briefly  describe  each  HSI  deliverable  or 
accessible  data  product  specified  in  the  contract. 

(s)  Time-phase  schedule  and  level  of  effort.  Provide  a  milestone  chart  that  identifies  each  separate 
HSI  activity  to  be  accomplished  during  the  contract  period  of  performance.  Include  key  HSI  decision 
points  and  their  relationship  to  program  milestones.  Provide  information  on  the  proposed  number  of 
personnel  on  an  annual  basis. 

(t)  HSI  quality  control.  Describe  the  approach  for  assessing  and  reporting  on  the  quality  (relative 
success  and  progress)  of  the  overall  HSI  effort  and  each  HSI  domain  over  the  course  of  the  contract. 
Describe  the: 

1.  Approach  for  assessing  the  following  contributors  to  HSI  success. 

2.  Implementation  of  HSI  policy  and  processes. 

3.  Implementation  of  a  human-centered  design  process; 

4.  Education  and  qualifications  of  HSI  personnel. 

5.  HSI  involvement  in  subcontractor  requirements  and  selection. 

6.  Availability  and  use  of  HSI  tools. 

7.  HSI  participation  in  testing  and  verification. 

End  of  DI-HF AC-8 1743 A/T  (SMC). 
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